[dmarc-discuss] dmarc-discuss Digest, Vol 19, Issue 7

Lori Ruff lruff at integratedalliances.com
Wed Jul 17 13:27:34 PDT 2013


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, <dmarc-discuss-request at blackops.org> wrote:

> Send dmarc-discuss mailing list submissions to
>         dmarc-discuss at dmarc.org
>
> 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
>         dmarc-discuss-request at dmarc.org
>
> You can reach the person managing the list at
>         dmarc-discuss-owner at dmarc.org
>
> 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 <doug.mtview at gmail.com>
> To: Roland Turner <roland.turner at trustsphere.com>
> Cc: "dmarc-discuss at dmarc.org" <dmarc-discuss at dmarc.org>
> Subject: Re: [dmarc-discuss] multiple from
> Message-ID: <4CD6EAD3-6015-4C12-9CAA-20222D2342D5 at gmail.com>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Jul 16, 2013, at 8:46 PM, Roland Turner <roland.turner at trustsphere.com>
> 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 <msk at fb.com>
> To: "dmarc-discuss at dmarc.org" <dmarc-discuss at dmarc.org>
> Subject: Re: [dmarc-discuss] multiple from
> Message-ID:
>         <
> C8869BE93CF766409D9086A78338CEE9388FD782 at PRN-MBX01-5.TheFacebook.com>
> Content-Type: text/plain; charset="us-ascii"
>
> On 7/16/13 8:46 PM, "Roland Turner" <roland.turner at trustsphere.com> 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" <johnl at taugh.com>
> To: dmarc-discuss at dmarc.org
> Subject: Re: [dmarc-discuss] options on multiple from
> Message-ID: <20130717173230.65635.qmail at joyce.lan>
> 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 <fmartin at linkedin.com>
> To: John Levine <johnl at taugh.com>
> Cc: "<dmarc-discuss at dmarc.org>" <dmarc-discuss at dmarc.org>
> Subject: Re: [dmarc-discuss] options on multiple from
> Message-ID:
>         <77426B543150464AA3F30DF1A91365DE53B516BE at ESV4-MBX01.linkedin.biz>
> Content-Type: text/plain; charset="us-ascii"
>
>
> On Jul 17, 2013, at 10:32 AM, John Levine <johnl at taugh.com> 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" <johnl at taugh.com>
> To: "Franck Martin" <fmartin at linkedin.com>
> Cc: "<dmarc-discuss at dmarc.org>" <dmarc-discuss at dmarc.org>
> Subject: Re: [dmarc-discuss] options on multiple from
> Message-ID: <alpine.BSF.2.00.1307171458540.65977 at joyce.lan>
> 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, johnl at taugh.com, Taughannock Networks, Trumansburg NY
> "I dropped the toothpaste", said Tom, crestfallenly.
>
>
> ------------------------------
>
> _______________________________________________
> dmarc-discuss mailing list
> dmarc-discuss at dmarc.org
> 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
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.dmarc.org/pipermail/dmarc-discuss/attachments/20130717/fe621567/attachment-0001.htm>


More information about the dmarc-discuss mailing list