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.
It opens a can of worms, Pandora's box, so to speak, to begin
suggesting one can modifying and tampering with one the key x822/5322
mail headers, From:, for any local reason.
In my ethical engineering book, it would just be major TABOO to do
this. The 5322.From one is the anchor for fundamental electronic mail
I/O for both networking and non-networking and for other technologies.
To tamper with it, it is bound to break other things.
Keep in mind, ADSP also proposed a "radical" DISCARD concept for mail.
But because of the ADSP standard track work and synergism at the
time, we did get RFC2821BIS (RFC5322) to recognize the new reality
that there are new reasons to ACCEPT and DISCARD rather than ACCEPT
and BOUNCE without referring to the ADSP work (it was still a draft).
side note:
There was also a new modern reality where the SMTP DATA state point
would be used more as a CALL OUT, SHIM, HOOK to handle new RFC5322
based Payload technology such as DKIM verification where a ADSP
policy check would also apply. One main goal was dynamic processing
with instant non-bounce notifications. But with ADSP, there was
suggestions for an implementation to set a ADSP fail that allows
the acceptance of mail so it can be quietly discarded. IOW, no
dynamic 55x rejection at the SMTP level for ADSP fail policies
because
that caused problems for the blind mailing list servers.
Yes, it is all complex, but here, the real solution is for John Levine
and other large list operators to update their mail listing software
to follow the suggestions in RFC6377:
RFC6377 DomainKeys Identified Mail (DKIM) and Mailing List
Its not a new problem, its been known since 2006. There are secondary
DKIM security "wrapper" layers that augment DKIM. DMARC may be the
focus, but the issue existed since SSP and ADSP. If the list service
is going to resign mail with DKIM, it needs to recognize that DKIM
does comes with signature security baggage that the not covered by the
trust model.
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. 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.
Etc. My main point is that we been doing this for 9+ years. We knew
the problems and we have the ideas for solutions. Whether it was all
practical and could scale, well, everyone had different opinions here.
But we got a different issue here when list operations don't want to
change to add policy protocol support but change enough to support a
pure DKIM-BASE but nothing else. I fail to see how it can work that way.
This is a "integration" issue and can only be solved using an
integrated DKIM+POLICY framework and mentality.
--
HLS