Brandon Long <blong@xxxxxxxxxx> wrote:
> With the understanding that my email is unlikely to be received by some
> of those having issues...
> Let us assume that those who specify p=REJECT have a good reason for
> doing so, and that after 2-3 years, they are unlikely to change back.
> Let us also assume that the members of these organizations who are
> participating in IETF may or may not have any power over whether their
> admins have decided to be p=REJECT.
> And let us assume that we want these folks to participate in IETF.
I agree with the statements, and I want people to participate.
> I will assume that if you're not willing to stipulate to the above,
> then you don't actually want a solution.
There is another option: the people who live in a p=reject policy regime
could use a different email address for IETF participation. It's not a
choice I like very much though.
> The middle man, ietf, can work around this today.
I can hold my nose and live with this solution.
I've been begging for *A* solution for three years now.
I want to put out that we are hacking a middle box to solve a problem with
end-points, and that whatever we do will become the "standard"
> mailman should also know how to tell the difference between a message
> specific policy bounce, and particular DMARC bounces, and should apply
> different heuristics to handling them. I have no idea if that existing
> in any version of mailman or is a planned feature.
It is not.
It would be nice if the need to fund this work had been considered when the
p=reject policy code was being written at the various places that wanted it.
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works
-= IPv6 IoT consulting =-
Attachment:
signature.asc
Description: PGP signature