Agree with your assumptions ( and the later point that receiving person can't
controls what their admins do any more than sender can control what their
admins do)
But there are two failure modes for something like this
1) sender knows their email was not received
2) email was not received by a bunch of people and neither the sender nor
receiver knows that
The second failure mode is much worse than the first.
On Nov 2, 2016, at 3:58 PM, Brandon Long <blong(_at_)google(_dot_)com> 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 will assume that if you're not willing to stipulate to the above, then you
don't actually want a solution.
We are then left with only moving forward.
If this is a problem for you as a receiver, you can choose to attempt to
whitelist the ietf mailing list mail from DMARC enforcement. You may not be
able to do so, just like the sender may not be able to change their
organizations DMARC record.
The middle man, ietf, can work around this today. They need to run a new
enough version of mailman and enable one of the workarounds. For mailman,
this means munging the mail, usually the From header. It's not pretty, but
it works, it works now, and it will work for everyone. The difference is
mostly cosmetic, though depending on your mail client, there may be other
downsides. And it may violate RFC 5322.
I don't think this is possible with mailman, but theoretically it is also
possible for a mailing list to pass the message through without breaking the
DKIM signature. This means no footers and no subject tags. Which of these a
list would choose is probably dependent on the list members.
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.
There is a proposed standard, ARC, that would allow mail receivers to do more
intelligent whitelisting. It's not ready yet.
It is unfortunate that these types of choices have to be made.
Brandon
On Wed, Nov 2, 2016 at 12:00 PM, Michael Richardson
<mcr+ietf(_at_)sandelman(_dot_)ca> wrote:
Cullen Jennings <fluffy(_at_)iii(_dot_)ca> wrote:
> So if someone send a email with a bad signature to an IETF list from a
> domain that has a reject policy, and the IETF server forwards it to my
> email email provider, my email provider rejects it. Now the IETF email
> server counts that as a bounce. Too many bounces in a row and the IETF
> server unsubscribes me from the list.
> This does not seem OK that anyone can trivially send some SPAM and get
> me unsubscribed.
yeah, that's a real problem isn't it.
After nearly three years of yelling about this problem, we are not even close
to consensus that it's a problem, with many people suggesting that IETF
mailing
list software should just munge headers.
DMARC WG was supposedly designing a solution. I don't know where that is.
My take is that IETF mailing list software should reject email from p=reject
senders, since that's their stated policy.
The original threads include:
https://www.ietf.org/mail-archive/web/ietf/current/msg99659.html
> What's the right advice on how the IETF server should be run?
> Now to a more detailed problem - Jana sends lots of email to the quic
> list. I don't get any of them. It appears that my email server (run by
> rackspace) rejects them with an
> Diagnostic-Code: smtp; 550 5.7.1 Email rejected per DMARC policy for
> google.com (G15)
> If Jana sends the email directly to me, it works. This seems to point
> at the IETF server is doing something that breaks signature in Jana
> email.
Jana needs to stop sending from google.com.
Their policy is that not to forward, so sad to lose all the google.com
contributors.... we really shouldn't violate their stated policy.
--
Michael Richardson <mcr+IETF(_at_)sandelman(_dot_)ca>, Sandelman Software
Works
-= IPv6 IoT consulting =-
_______________________________________________
dmarc mailing list
dmarc(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/dmarc