ietf
[Top] [All Lists]

Re: Mailing list membership.

2017-03-01 18:36:54
super! But what are this attributes, that brings the "DMARC honoring
providers" to hiccup? (in german Schluckauf).

I'm not sure what you're asking, but let me explain "the DMARC
problem", in case that's what you want to know (and for any who aren't
already aware of it):

- Bob posts to a mailing list from <bob(_at_)example(_dot_)com>, and example.com
is a domain that publishes a DMARC record with the "p=reject"
parameter.

- (The example.com domain does this because it doesn't like people to
send mail that says "From: <address(_at_)example(_dot_)com>" when the mail is 
not
actually from an address at example.com.  It's a brand-protection
issue, to oversimplify a bit.)

- The mailing list prepends "[listname]" to the subject line, and
probably sticks some "from the mailing list" text at the end of the
message... and then sends it on to the subscribers, leaving the
"From:" line unchanged (so it still says <bob(_at_)example(_dot_)com>).

- Carol and Ted and Alice are all mailing list subscribers, so each of
them is sent a copy of the message.

- Alice is <alice@nicedomain.example>, and nicedomain.example looks up
and honours DMARC records.

- The nicedomain.example mail server checks SPF.  It looks up the SPF
record for example.com and it sees that the IP address the mail is
coming from (which belongs to the list sever) is not authorized to
send mail as example.com.  So the SPF check fails.

- The nicedomain.example mail server checks DKIM.  It finds the DKIM
signature in the message and tries to verify it.  But the changes the
list server made to the message (the subject line and the stuff at the
end) broke the DKIM signature.  So the DKIM check fails.

- The nicedomain.example mail server has not been able to authenticate
the message with respect to the domain in the "From" line
(example.com), so it looks up example.com's DMARC record to see what
example.com's policy says.  And it says "p=reject".

- Honouring that, nicedomain.example rejects ("bounces") the message.

- The bounce message goes back to the mailing list server.

- The mailing list server sees that a list message it sent to Alice
bounced, so it increments the bounce count for Alice.

- After a few such messages, Alice's bounce count exceeds the
threshold for the mailing list software, and she is unsubscribed from
the list.

Now, of course, Alice can re-subscribe, but the same thing will
eventually happen again... and again.

Some workarounds include asking Bob to post from an address at a
domain that doesn't publish "p=reject", and/or asking Alice to
subscribe from an address at a domain that doesn't reject messages
based on DMARC policies.  There are also workarounds that can be done
in the list server, each of which creates its own problems.  None of
these workarounds are ideal.

The DMARC working group is working on a protocol called ARC, which is
aimed at fixing some of these issues.

(Hoping this has helped some people to understand what's going on...)

-- 
Barry