On 03/11/2016 10:58, Brandon Long 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.
Let me stop you right there. Yes, we want everybody to be free to
participate in the IETF, and presumably those people want to participate
in the IETF. But participants have to be able to use the tools that the
IETF has chosen, which includes mailing lists. That's always been true.
(In 1992, when I started in the IETF, it meant knowing how to subscribe
to a majordomo list. Today, subscribing is a bit easier, but it means
avoiding the DMARC trap.)
So such participants need to use an email sending address that works
with IETF mailing lists.
yahoo.com and google.com don't work properly with IETF mailing lists.
Fortunately, very fine alternatives are available, such as gmail.com.
(gmail's spam learning is even smart enough to work around p=reject,
as it did for this very message that I'm replying too.)
I think Michael Richardson made a very valid point. If our mailing
list software detects a sender whose domain has p=reject, we *know*
that the forwarded message will fail DMARC validation. So there's a
strong case for rejecting the message immediately, so that the sender
can be told about the problem and can choose a different sending address.
Presumably, we'd only need to do this until ARC is deployable.
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.
No, it's actually not cosmetic, for reasons that Dave Crocker pointed out.
Regards
Brian
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