On May 7, 2013, at 5:55 PM, Franck Martin <fmar...@linkedin.com> wrote:
> On May 7, 2013, at 5:36 PM, Matt Simerson <m...@tnpi.net> wrote:
>
>>> When a message has non-existent/invalid/etc domain in From, should it be
>>> treated as failed the DMARC test, or DMARC is not applicable here?
>>
>> https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1
>>
>> Section 15.1:
>>
>> The absence of a single, properly-formed RFC5322.From field renders
>> the message invalid.
>>
>> The complete answer is more complex, obviously, but is also covered amply in
>> the draft.
>
> This is something which is in other RFCs.
>
> For instance, RFC5322 3.6 specifies that an email must contain one and one
> only From: headers
>
> 3.6.2 requires that there is at least one domain name in that field.
>
> (but who has enforced that so far?)
Me:
https://github.com/qpsmtpd-dev/qpsmtpd-dev/blob/master/plugins/headers
And I got the idea from Haraka, as I note in the comments. So that's at least
two SMTP MTAs that do it. :-)
> Now if you have more than one email address with multiple domains in that
> field. The spec says, to evaluate each one with DMARC and take the most
> restrictive action...
Maybe it *used* to say that. The current version says:
A message bearing multiple RFC5322.From identifiers is ambiguous
under DMARC. This includes messages with multiple RFC5322.From
fields (which is also forbidden under [MAIL]) and a message with a
single RFC5322.From field containing multiple entities. There can
also be From: fields that contain no meaningful values, such as
RFC5322's "group" syntax. Such messages SHOULD be rejected. If they
are not, the Mail Receiver can either ignore the message entirely
with respect to DMARC processing, or evaluate DMARC against all
identifiers. In this latter case, it is important to consider the
set of identifiers that will ultimately be shown to end users, since
ensuring the legitimate use of those identifiers is at the heart of
DMARC's goal. This requires an understanding of the end user
environment, the specification of which is outside of the scope of
this document.
I decided that since making this decision is outside the scope of this version
of DMARC, it is outside the scope of my implementation in Mail::DMARC. Whatever
is calling Mail::DMARC can call it separately for each header_from address, or
just the first, or last, or whatever.
I personally will be calling it from a Qpsmtpd plugin, so DMARC will never get
called on such messages. They will have been rejected before DMARC checking
kicks in.
Matt
_______________________________________________
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)
