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)
