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