[dmarc-discuss] DMARC On AmazonSES

Umesh Ratnayake umesh at force24.co.uk
Wed Jul 17 13:43:50 PDT 2013


Hi everyone! 

I'm just wondering, does anybody implemented DMARC record in a client DNS Record that uses Amazon SES as the deliverability platform before?

If so, can you give me the best practices that you recon. to implement this please. 

I'm bit struck in a position where the Return path value always comes as amazonses.com where the intended senders domain is something different. 

Thank you in advance.

U Ratnayake


==================================================================================================
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: dmarc-discuss Digest, Vol 19, Issue 7 (Lori Ruff)


----------------------------------------------------------------------

Message: 1
Date: Wed, 17 Jul 2013 12:39:15 -0700
From: Douglas Otis <doug.mtview at gmail.com>
To: Murray Kucherawy <msk at fb.com>
Cc: "dmarc-discuss at dmarc.org" <dmarc-discuss at dmarc.org>
Subject: Re: [dmarc-discuss] multiple from
Message-ID: <61526550-A885-4C4D-B806-D8A87BB30CE4 at gmail.com>
Content-Type: text/plain; charset=us-ascii


On Jul 17, 2013, at 9:40 AM, Murray Kucherawy <msk at fb.com> wrote:

> 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.

Murray,

The situation with SPF is a bit different as it represents an authorization of servers that handle the _entire_ message.  When a server is trustworthy it can be reasonable to assume messages received can be trusted.  DMARC changes this by basing acceptance on a DKIM signing domain where ANY latitude permitted by DKIM's partial message coverage MUST BE seen as an exploitable vulnerability.  This is a problem created when for example DKIM ignores invalidly prefixed header fields, which unfortunately is normal with DKIM.

Your characterization is accurate but DKIM was intended to be safely deployable within what was already understood to be this situation.  The DKIM deployment documentation even suggests when a DKIM signature is trusted, message content filtering can be bypassed.  Neither DKIM nor the Results-Authentication header offers any status about whether invalidly prefixed header fields were checked and it is rare for DKIM signing domains to implement the double entry of singleton header fields.  This situation leaves DKIM's status untrustworthy and this will not change significantly anytime in the near future.

Acceptance based upon server authorization or authentication will not create an incentive to invalidly prefix header fields aimed specifically at being deceptive.  It is also foolhardy to describe bayesian spam filtering that can never represent a static implementation.  Nor is it accurate to suggest any invalidly prefixed header is either malicious or spam when DKIM is not used.  When acceptance is based on a DKIM signing domain where content filters are likely bypassed as described in DKIM's deployment RFC and implemented in Sendmail milters, this creates an environment ideal for phishing that ironically DKIM was intended to prevent as suggested in the deployment introduction.

There really needs to be an RFC that documents how to combine the status of checking for invalidly prefixed header fields with the status returned by DKIM since an easy solution of declaring the signature invalid has been rejected.  Perhaps this check could also include checks against use of invalid UTF code points when internationalized header fields are being used.  Avoid the rabbit hole of describing how spam or phish is detected.

DMARC should not over reach and attempt to dictate what can be accepted from domains not directly related with policy domains above the public suffix.  Perhaps it would be better to describe this as apex of the "registered" domains.

Regards,
Douglas Otis











------------------------------

Message: 2
Date: Wed, 17 Jul 2013 15:27:34 -0500
From: Lori Ruff <lruff at integratedalliances.com>
To: dmarc-discuss at blackops.org
Subject: Re: [dmarc-discuss] dmarc-discuss Digest, Vol 19, Issue 7
Message-ID:
        <CAN-3vuShYNuFWbAkeZjU9UKHN+Kc_bG=S8tT21B-xm0+s6uzVg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

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.htm>

------------------------------

_______________________________________________
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 8
********************************************


More information about the dmarc-discuss mailing list