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.
On Jul 16, 2013, at 9:15 AM, Douglas Otis <[email protected]> wrote: > > On Jul 16, 2013, at 8:20 AM, Franck Martin <[email protected]> wrote: > >> On Jul 16, 2013, at 8:02 AM, Andreas Schulze <[email protected]> wrote: >> >>> Am 16.07.2013 09:31 schrieb Tim Draegen: >>>> On Jul 16, 2013, at 9:19 AM, Andreas Schulze <[email protected]> >>>> 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. > > Regards, > Douglas Otis _______________________________________________ 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)
