Re: DMARC: perspectives from a listadmin of large open-source lists

[Alessandro Vesely <[e-mail]>]

On Sun 13/Apr/2014 19:37:35 +0200 Hector Santos wrote:
> On 4/11/2014 6:40 AM, Alessandro Vesely wrote:> On Tue 08/Apr/2014
> 19:34:35 +0200 John R Levine wrote:
>>>
>>> Just today I did modify it so that any list mail with a From: address
>>> @yahoo.com is re written to @yahoo.com.INVALID.  That's the least
>>> intrusive way I've been able to come up with to mitigate the damage.
>>
>> Fair enough.  I've copied that suggestion to
>> http://en.wikipedia.org/wiki/DMARC#Human_policy
>> Please feel free to amend that page at your leisure.
>>
> 
> Hi Alessandro,
> 
> You added (I presume):
> 
>    According to John Levine, a well known mail expert, the least
>    intrusive way to mitigate the damage would be to rewrite the
>    From: address in a predictable, comprehensible manner, such as
>    the following:
> 
> It may be the "quickest" way, but I would consider this the most
> intrusive and even email damaging, extremely harmful suggestion to
> electronic mail communications.

Ok, I added "temporarily", so it now reads:

   Various workarounds have been proposed to cope with domains that
   publish strict policies unwittingly. For example, a mailing list
   manager should reject posts from authors who use problematic email
   domains. The latter behavior is the most respectful the
   communication protocols as well as the domain owner's will.
   However, it might cause inconveniences in the face of sudden
   policy changes. According to John Levine, a well known mail
   expert, the least intrusive way to temporarily mitigate the damage
   would be to rewrite the From: address in a predictable,
   comprehensible manner, such as the following:

In the preceding "History" section, I appended:

   In April 2014, Yahoo changed its DMARC policy to p=reject, thereby
   causing misbehavior in several mailing lists.[6] DMARC is not yet
   a standard protocol, and currently misses a provision for such
   sudden changes.

Is that more acceptable?

> [...]
> So this is a "integration" issue.  Honestly, the changes are not too
> difficult and IMO, it is far less intrusive than changing the 5322.From.
> 
> 1) When a new subscriber applies to a list, check for restrictive
> domain policies. Deny subscribers and explain why in the notification
> message.
> 
> 2) Check for restrictive domains in list mail submissions.
> 
> The first one is the piece a cake.

Yes

> The 2nd one can be more complex
> due to the wider number of software things to do here.
> 
> 2a) Dynamic SMTP check, reject (55x) the message with policy reason.
> 
> 2b) Accept message and send a "no access" notification message.
> Explain why.
> 
> 2c) During the redesign software change, write a one time membership
> scanner to remove restrictive domain members. Send email notification
> explaining why.

I think (2c) has to be done politely, in order to allow people the
time to react adequately.

Ale