Re: [dmarc-ietf] Composition Kills: A Case Study of Email Sender Authentication

[John Levine <[e-mail]>]

In article <[e-mail]> you write:
>The paper has a simplistic model of email anti-abuse processing and this 
>distorts some of its analysis.  At the least, the paper needs to 
>distinguish between theory and practice.

Yup.

>> SPF implementations treat “([e-mail]” as anempty MAIL FROM 
>> address, and thus forward the resultsof checking HELO to the DMARC 
>> component, because thestring in the parentheses can be parsed as a 
>> comment ac-cording to RFC 5322 [10]. Some DMARC 
>> implementations,however, may take it as a normal non-empty address,
>
>1. This issues goes away if SPF supplies DMARC the domain name, rather 
>than DMARC having to fetch it

Their assumptions about DMARC validators may be true in some cases but
not in general.  In OpenDMARC which is pretty widely used, the caller
tells the DMARC library what domain SPF checked, whether it was the
mail_from or helo, and what the result was.

>The paper asserts that AR is used as DMARC input.  I suspect that is 
>rarely, if ever, true.  Yes? No?

I'd say never.  To do DMARC rejects you have to do all of the
validation in the SMTP daemon, which is before anything has a chance
to create an A-R header.

>The rfc5322.From: field is independent of MIME. MIME pertains only to 
>the body.

The display name can be a MIME encoded word, but that has nothing to do with
parsing the MIME parts in the body of the message.

I'm still impressed at some of the really simple bugs they exploited,
like NUL characters in header fields.

R's,
John