Re: [dmarc-discuss] Still having problems with third-party sending
Eric Johnansson wrote:
Maybe the misunderstanding speaks to a common conceptual model for
outsiders?
what are the implications of generalizing selectors to identifying different
streams?
The relevant DKIM construct would appear to be the signature domain parameters
(d={something}). This would seem like a more fruitful approach, although you'd
need your customer's co-operation on extracting and forwarding to you the DMARC
feedback rows which use your allocated sub-domain. So:
_dmarc.example.com IN TXT ...adkim=r... (or no adkim=)
From: Example Inc. someth...@example.com
DKIM-Signature: ...d=sender.example.com...
The relaxed alignment rules only require that the 5322.From domain and the d=
domain belong to the same organisational domain, not that either be a parent of
the other.
More broadly, I appear to have missed the motivation for what you're doing:
DMARC implementations are most frequently aimed at detecting unauthorised[1]
use of domain names and are therefore an organisation-wide concern, rather than
that of an outsourced sender. They have some use as a check on misconfiguration
of sending infrastructure but, again, if an organisation is already using DMARC
to monitor unauthorised use of their domain names then identifying errors of
this type is a straight-forward part of what they're already doing. What are
you trying to use DMARC to achieve?
- Roland
1: No doubt someone will argue about the appropriate adjective here. It doesn't
change the argument about DMARC implementations generally being
organisation-wide concerns.
___
dmarc-discuss mailing list
dmarc-discuss@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)
Re: [dmarc-discuss] Still having problems with third-party sending
- Original Message - From: John Levine jo...@taugh.com To: dmarc-discuss@dmarc.org Cc: e...@in3x.io Sent: Thursday, August 20, 2015 1:57:19 PM Subject: Re: [dmarc-discuss] Still having problems with third-party sending DKIM and DMARC and for that matter SPF are not designed to distinguish among authorized senders for the same domain. If you want to manage multiple mail streams independently, use subdomains. - From addresses should look like: x...@intelli-shop.com . Use something like x...@email.intelli-shop.com. They can delegate email.intelli-shop.com to you, then you can set up all of the DKIM and SPF and DMARC stuff for that subdomain any way you want. If you look at the mail coming from large brands, you'll see that's pretty common. I've been looking at examples. I'm not sure how to solve the problem of recipient perception of the subdomain. we have been so effective at convincing people that email addresses that look different from what you are expecting are a phishing attack and they should simply delete it that they do not respond to our subdomain emails but still fall for real pishing. yes, the irony is not lost on me. also, the DMARC third party methods seem to be aimed at solving the one way communications problem (newsletters, bills, notices) and not where the bulk mail is the start of a two way conversation. another issue with subdomains is the return address. maybe a customer can alias one domain on top of another but that also triggers suspicion on the part of the recipient. not sure how to handle that one. DKIM selectors are for key management, not to create multiple mail streams visible to outsiders. You're not the first to have that misunderstanding but I don't know how to make it any clearer in the documentation. Maybe the misunderstanding speaks to a common conceptual model for outsiders? what are the implications of generalizing selectors to identifying different streams? ___ dmarc-discuss mailing list dmarc-discuss@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)
Re: [dmarc-discuss] Still having problems with third-party sending
I'm trying to improve my understanding of the third-party sender problem when, for reasons technical and political, you want to maintain a distance between organizational domain and the working domain. DKIM and DMARC and for that matter SPF are not designed to distinguish among authorized senders for the same domain. If you want to manage multiple mail streams independently, use subdomains. - From addresses should look like: x...@intelli-shop.com . Use something like x...@email.intelli-shop.com. They can delegate email.intelli-shop.com to you, then you can set up all of the DKIM and SPF and DMARC stuff for that subdomain any way you want. If you look at the mail coming from large brands, you'll see that's pretty common. DKIM selectors are for key management, not to create multiple mail streams visible to outsiders. You're not the first to have that misunderstanding but I don't know how to make it any clearer in the documentation. R's, John ___ dmarc-discuss mailing list dmarc-discuss@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)
Re: [dmarc-discuss] Still having problems with third-party sending
I've been looking at examples. I'm not sure how to solve the problem of recipient perception of the subdomain. we have been so effective at convincing people that email addresses that look different from what you are expecting are a phishing attack and they should simply delete it that they do not respond to our subdomain emails but still fall for real pishing. yes, the irony is not lost on me. Take a look at some of stuff you get from big brands. People don't seem to find off...@email.bigcorp.com very different from off...@bigcorp.com. These days most MUAs don't even show the address, just the From: header comment. another issue with subdomains is the return address. maybe a customer can alias one domain on top of another but that also triggers suspicion on the part of the recipient. not sure how to handle that one. Same answer. Suspicion? Of an address they don't even see? DKIM selectors are for key management, ... Maybe the misunderstanding speaks to a common conceptual model for outsiders? I believe it is more due to not reading the documentation. what are the implications of generalizing selectors to identifying different streams? You have something that is not DKIM. See RFC 6376, particularly section 3. You've already got the answer -- if you want the streams all to use the same domain, whoever manages the domain has to manage the DNS records, and if you want DMARC reports, arrange for someone to receive the reports and process them however is useful, which might include segmenting them by characteristics known to the domain manager. If the domain manager cannot or will not do that, use subdomains or different domain names. R's, John ___ dmarc-discuss mailing list dmarc-discuss@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)
