[dmarc-discuss] multiple from

Douglas Otis doug.mtview at gmail.com
Tue Jul 16 10:07:35 PDT 2013


On Jul 16, 2013, at 9:28 AM, Franck Martin <fmartin at linkedin.com> wrote:

> On Jul 16, 2013, at 9:15 AM, Douglas Otis <doug.mtview at gmail.com> wrote:
> 
>> On Jul 16, 2013, at 8:20 AM, Franck Martin <fmartin at linkedin.com> wrote:
>> 
>>> On Jul 16, 2013, at 8:02 AM, Andreas Schulze <sca at andreasschulze.de> wrote:
>>> 
>>>> Am 16.07.2013 09:31 schrieb Tim Draegen:
>>>>> On Jul 16, 2013, at 9:19 AM, Andreas Schulze <sca at andreasschulze.de> wrote:
>>>>> This section of the spec mentions multiple Froms, it's a tricky thing:
>>>>> 	http://tools.ietf.org/html/draft-kucherawy-dmarc-base-01#section-10.1
>>>>> 
>>>>> About the Sender: header:
>>>>> 	http://tools.ietf.org/html/draft-kucherawy-dmarc-base-01#appendix-A.3
>>>> 
>>>> Hm. tomatoes on my eyes ...
>>>> Thanks, Tim!
>>> 
>>> In my experience, I have seen multiple email address in the From: with badly configured bounces, or display attack, or a repetition in the display part of the email address.
>>> 
>>> While people speak it is in the RFC to have multiple emails in the From, it is hard to catch a real use case in the wild.
>>> 
>>> I found it simpler to disallow it (unless it is the same domain which is repeated cf bugs above)
>>> 
>>> I found more troubling that the IEA spec allows now to not put an email address in the From: something like undisclosed-sender;
>> 
>> Dear Franck,
>> 
>> From a specification standpoint, it seems odd to invalidate email from otherwise uninvolved domains that are technically RFC compliant.  Wouldn't such specifications make the DMARC specification RFC ignorant?  RFC5322 is a draft standard and RFC6854 is standards track.  Requiring rejection of otherwise valid messages is hostile to those following standards.  While I might agree RFC6854 should never have been adopted, isn't it wrong to reject valid messages? 
>> 
>> Prior to DKIM which is often use as a means to bypass problematic bayesian filter results per RFC6873, invalidly prefixed header fields were often due to poorly written automated mail handlers and were not malicious.  With DKIM processing the entire header field stack and yet still ignoring invalidly prefixed header fields and declaring signatures valid, the occurrence of prefixed header fields in conjunction with DKIM now likely represents an attempt to exploit DKIM's oversight.  With malefactors becoming increasingly proficient at poisoning statistically based processes, DKIM's oversight now requires additional processing that would have been otherwise unnecessary.  It seems that DMARC is now using this subsequent processing to justify an overreach.
> 

> This is me, and not DMARC. I don't see any value in such emails and too much pain to accommodate something with a usage of 0.0000000001% of mail traffic.


Dear Franck,

Since RFC6854 and internationalization of header fields is relatively new, assumptions about percentages of use while ignoring compliance could prove problematic in the fairly near future.  There must be a better way.

Regards,
Douglas Otis


More information about the dmarc-discuss mailing list