help *Keep it Real & Rock On!*
*Lori Ruff* *720-897-8252 Direct* * * *If you’d like to learn more about LinkedIn, register for free training and resources at **http://RockLinkedIn.com* <http://rocklinkedin.com/>*! * * * *Fresh News: * *Forbes Top 10 Women Social Media Power Influencer 2013 ** http://rckstr.us/YzmDMm* <http://rckstr.us/YzmDMm>* * *Top 23 Social Media Power Influencers of 2012 **http://rckstr.us/WVEBTP*<http://rckstr.us/WVEBTP> ** *Moody’s Top 50 Favorite People of 2012* *http://rckstr.us/V2nQeZ*<http://rckstr.us/V2nQeZ> * * Disclaimer: The LinkedIn Diva does not work for LinkedIn, but for the LinkedIn user community, to support, educate and empower their business results. Privacy and Confidentiality Notice: This e-mail message contains information that is confidential and/or privileged. If you are not the intended recipient, please advise the sender and delete this message immediately. On Wed, Jul 17, 2013 at 2:00 PM, <[email protected]> wrote: > Send dmarc-discuss mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.dmarc.org/mailman/listinfo/dmarc-discuss > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of dmarc-discuss digest..." > > > Today's Topics: > > 1. Re: multiple from (Douglas Otis) > 2. Re: multiple from (Murray Kucherawy) > 3. Re: options on multiple from (John Levine) > 4. Re: options on multiple from (Franck Martin) > 5. Re: options on multiple from (John R Levine) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 17 Jul 2013 04:57:05 -0700 > From: Douglas Otis <[email protected]> > To: Roland Turner <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [dmarc-discuss] multiple from > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > > On Jul 16, 2013, at 8:46 PM, Roland Turner <[email protected]> > wrote: > > > On 07/17/2013 12:15 AM, Douglas Otis wrote: > > > >> 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. > > > > This viewpoint is incorrect and reflects an error in understanding that > senders frequently make. > > > > An SMTP server (or the host that it runs on) is the property of a > receiver. When a sender offers a message for delivery, the sender is asking > the receiver to extend a delivery privilege, a privilege that the receiver > is free to decline for any reason or for no reason. > > Dear Roland, > > Respect the rights of receivers over that of senders? Absolutely! > > There remains a need to defend receivers, and that is a clear reality. > > Asserting negative reputations against questionable DKIM domains carries > significant risk because: > 1) DKIM does not constrain message recipients. > 2) DKIM does not constrain the initiating servers. > 3) DKIM does not constrain the entire message. > 4) DKIM can be replayed by design. > > While DKIM is ideal for BULK senders, DKIM completely ignores what is > needed by third-parties to defend receivers. > > On top of that, SPF expects receivers to make as many as 111 DNS > transactions to resolve Return Path authorizations which may include > un-cacheable macro expansions? > > SPF macros are a rarely used option, when combined with DMARC, becomes an > obligatory role for receivers on behalf of senders. > > To be more compliant, DMARC now wishes to couple Return Path authorization > with any number of DKIM signatures where alignment with either DKIM or the > Return Path must be determined for each of the FROM email domain(s)? > > Unlike Server Authentication where XMPP offers a good and workable > example, DKIM, by its design, potentially permits abuse of receivers. > > DMARC recommends acceptance using EITHER SPF or DKIM after checking policy > at domain(s) above the public suffix. > > DMARC does not deal with the issue created by RFC6854 which can be easily > accommodated using the XMPP scheme of server authentication. > > Add a scheme similar to that of ATPS, and this would represent a > defendable lightweight system able to defend receivers that DMARC/DKIM/SPF > is unable to accomplish. There remains a need to defend receivers this > remains a clear reality. > > Regards, > Douglas Otis > > > > > > ------------------------------ > > Message: 2 > Date: Wed, 17 Jul 2013 16:40:48 +0000 > From: Murray Kucherawy <[email protected]> > To: "[email protected]" <[email protected]> > Subject: Re: [dmarc-discuss] multiple from > Message-ID: > < > c8869be93cf766409d9086a78338cee9388fd...@prn-mbx01-5.thefacebook.com> > Content-Type: text/plain; charset="us-ascii" > > On 7/16/13 8:46 PM, "Roland Turner" <[email protected]> wrote: > >Any time an RFC and reality diverge, it it the RFC that is > >reality-ignorant, not reality that is RFC-ignorant. > > > >If it happens that the DMARC specification reflects reality better than > >existing RFCs - even standards track ones - then once again, it is those > >RFCs that are in error, not the DMARC specification. > > I don't agree with the first generalization. RFCs specifying the format > of an Internet message have existed for a really long time. It's reality > that decided to diverge, largely out of laziness: Email generating code > would be sloppy and cut corners, and user pressure caused mail submission > agents and other services to tolerate it rather than be strict about it. > We're left with a system where lots of software now supports the lazy > implementations. > > There's a draft making its way through the IETF now that describes this > situation, pleads with software to become strict once again, and then goes > into a list of common malformations and provides advice about how to > handle or interpret them. But even that advice about safe handling > doesn't render those messages compliant; they are still broken. > > DMARC's acknowledgement of reality doesn't make those RFCs wrong, nor does > it excuse various components' lax enforcement of the rules. > > -MSK > > > > > ------------------------------ > > Message: 3 > Date: 17 Jul 2013 17:32:30 -0000 > From: "John Levine" <[email protected]> > To: [email protected] > Subject: Re: [dmarc-discuss] options on multiple from > Message-ID: <[email protected]> > Content-Type: text/plain; charset=utf-8 > > It seems to me that there is a fairly short list of ways that DMARC can > deal > with addresses with more than one address on the From line: > > a) exclude them, anything with multiple addresses fails > b) if the two addresses are in the same domain, do the usual thing, > otherwise fail > c) evaluate separately, take the strictest result > d) evaluate seaparetly, take the loosest result > > Fail would probably mean to apply the failure rule for each domain so a) > is in > practice pretty close to c) > > I think it is reasonable to say that if you want to use DMARC, don't > use multiple addresses, since it's not a feature that is well > supported anywhere. > > > > ------------------------------ > > Message: 4 > Date: Wed, 17 Jul 2013 18:13:58 +0000 > From: Franck Martin <[email protected]> > To: John Levine <[email protected]> > Cc: "<[email protected]>" <[email protected]> > Subject: Re: [dmarc-discuss] options on multiple from > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="us-ascii" > > > On Jul 17, 2013, at 10:32 AM, John Levine <[email protected]> wrote: > > > It seems to me that there is a fairly short list of ways that DMARC can > deal > > with addresses with more than one address on the From line: > > > > a) exclude them, anything with multiple addresses fails > > b) if the two addresses are in the same domain, do the usual thing, > otherwise fail > > c) evaluate separately, take the strictest result > > d) evaluate seaparetly, take the loosest result > > > > Fail would probably mean to apply the failure rule for each domain so a) > is in > > practice pretty close to c) > > > > I think it is reasonable to say that if you want to use DMARC, don't > > use multiple addresses, since it's not a feature that is well > > supported anywhere. > > > > I'm not sure what fail means here? > 1) bounce the email > 2) dmarc test failed, so what policy to apply? > > If fail means bounce the email, then it contradicts earlier RFCs where > multiple emails in From is ok (and even none at all in a recent RFC). So it > is hard to be normative here when you contradict previous RFCs. You can > only provide advice to receivers on how to handle such emails (aka BCP). > > I encourage people to check their incoming mail streams and identify > emails with multiple addresses in From: and check which ones are valid > constructs or more caused by a buggy (or lazy as Murray said) MTA. > > > ------------------------------ > > Message: 5 > Date: 17 Jul 2013 14:59:22 -0400 > From: "John R Levine" <[email protected]> > To: "Franck Martin" <[email protected]> > Cc: "<[email protected]>" <[email protected]> > Subject: Re: [dmarc-discuss] options on multiple from > Message-ID: <[email protected]> > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > >> a) exclude them, anything with multiple addresses fails > >> b) if the two addresses are in the same domain, do the usual thing, > otherwise fail > >> c) evaluate separately, take the strictest result > >> d) evaluate seaparetly, take the loosest result > >> > >> Fail would probably mean to apply the failure rule for each domain so > a) is in > >> practice pretty close to c) ... > > > I'm not sure what fail means here? > > 1) bounce the email > > 2) dmarc test failed, so what policy to apply? > > Um, it means what I said it means in the message you quoted. > > Regards, > John Levine, [email protected], Taughannock Networks, Trumansburg NY > "I dropped the toothpaste", said Tom, crestfallenly. > > > ------------------------------ > > _______________________________________________ > 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) > > > > End of dmarc-discuss Digest, Vol 19, Issue 7 > ******************************************** >
_______________________________________________ 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)
