On 09/11/2012 20:54, Murray Kucherawy wrote:
Michiel,
I like your suggestion. However, protocol documents generally try very hard to
avoid getting into areas of user interface and human factors. I suspect that,
at best, this can be framed as operational advice down in an appendix or in
Security Considerations
+1 for Security Considerations (as previously suggested)
, or even left out in favor of a "best practices" document somewhere down the
line.
In addition, we had a similar debate during the development of DKIM. We decided that
DKIM is predicated on well-formed messages, so trying to push a mangled message through
the DKIM validation algorithm amounts to "garbage-in garbage-out".
The threat is inverted here:
* Auto-fixing messages before DKIM validation will prevent validation,
leaving the intent of the DKIM specification intact (no risk is
created of validating an invalid message).
* Auto-fixing messages that lack RFC5322.From headers after DMARC but
before presentation will render the intent of the DMARC
specification completely moot.
In an abstract sense this is just another instance of garbage-in,
however the automatic synthesis of absent RFC5322.From headers is so
widespread that ignoring it is putting form ahead of function.
Finally, we've already said this in the draft under the description "out of
scope":
"DMARC provides no advice about handling of malformed messages that might seek
to exploit message
processing weaknesses. There are other specifications and operational documents that
cover these issues."
... which are widely and automatically ignored (messages lacking
RFC5322.From are not merely accepted, the missing header is frequently
synthesised).
Note also that what's being proposed is not "how to deal with a
malformed message" but "how to deal with a malformed message if you
have/will automatically correct it, best practices notwithstanding".
- Roland
-MSK
From: Michiel van de Vis <[email protected]<mailto:[email protected]>>
Reply-To: <[email protected]<mailto:[email protected]>>
Date: Fri, 9 Nov 2012 08:49:19 +0100
To: <[email protected]<mailto:[email protected]>>
Subject: Re: [dmarc-discuss] Non existence of "From: " header
Hello,
Isn't it true that the scenario where there is no "From" header could increase
in popularity under 'spammers' when DMARC increases in acceptance (as it is now)?
Because using an invalid/non-aligned From would result in 100% rejects (given
the fact that the domain is in 100% DMARC reject mode), they could be looking
for other methodes to get they spam delivered (which they probably always will
be)?
I believe that the address the ISP displays as 'From' (whether they get it from
the RFC5322.From or RFC5321.MailFrom header) should match DMARC as this is the
address the user believes the e-mail is sent from.
/Michiel
DMARC Analyzer.com
2012/11/9 Zachary Harris
<[email protected]<mailto:[email protected]>>
On 11/08/2012 11:07 PM, John Levine wrote:
Has anyone, ever, seen a phish with no From: line and the phish target's
domain in the envelope?
I don't presently wish to offer any argument on the proposed absurdity
level of certain scenarios, but just a brief note to ensure clarity: if
an incoming MTA auto-generates From based on MailFrom when the former is
absent, as is presently the case over at Gmail for example, and if you
are only looking at the final product, then even by examining headers
you wouldn't realize that it was Fromless when it first arrived at your
doorstep.
-Zach
_______________________________________________
dmarc-discuss mailing list
[email protected]<mailto:[email protected]>
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms
(http://www.dmarc.org/note_well.html)
_______________________________________________ dmarc-discuss mailing list
[email protected]<mailto:[email protected]>
http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list
means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
_______________________________________________
dmarc-discuss mailing list
[email protected]
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms
(http://www.dmarc.org/note_well.html)
--
Roland Turner | Director, Labs
TrustSphere Pte Ltd | 3 Phillip Street #13-03, Singapore 048693
Mobile: +65 96700022 | Skype: roland.turner
[email protected] | http://www.trustsphere.com/
_______________________________________________
dmarc-discuss mailing list
[email protected]
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms
(http://www.dmarc.org/note_well.html)
