On 05/27/2013 12:09 PM, Matt Simerson wrote:
On May 26, 2013, at 8:20 PM, Roland Turner <[email protected]>
wrote:
This would impose an immense burden on receivers and, therefore, wouldn't get
out of the gate.
Receivers? I understand the burden this would place on senders (maintaining a
database will millions of key/values), but I'm not seeing the receiver burden.
"Immense" may be overstating it a little, but for a nett gain of
nothing, any cost is likely to be unacceptable. At the very least, new
code has to be developed and rolled out.
Receivers already perform a handful of DNS lookups and other forms of
validation upon every inbound connection.
Large Receivers go to considerable lengths to avoid performing _*any*_
[external] DNS lookups during inbound SMTP transactions, instead they
use pre-crawled DNS caches. Your proposal would fail on this criterion
alone.
Indeed, if you were willing to use a VERP scheme and assumed that
Receivers were willing to implement SPF's exists: mechanism (they're
not, in large part because they don't want to perform DNS queries during
inbound SMTP transactions...), you could implement something similar to
what you're describing with already deployed technology: use SPF to
authorise messages based upon determining by DNS callback whether they
have appropriately VERP'd return paths rather than on their source IP
address.
In effect the problem that you are trying to solve (changes made to messages
during forwarding break authentication) is insoluble in the way that you are
pursuing:
• Either you cause messages whose content differs materially from
something that an authorised sender sent to fail authentication, or
• you permit modified messages - whether modified by mailing list or by
spoofer - to pass.
A better approach (and the typical one) is to map the exit IP addresses of
well-behaved forwarders and ignore DMARC results for messages that come from
those addresses.
Well sure, I can whitelist individual well-behaved forwarders on my mail
server, but that's only half the problem. While some DMARC implementers have
obviously done this, many haven't, including Google and Yahoo.
Google's aggregate reports make pretty clear that they've done exactly
this. I've not checked Yahoo's.
I don't expect that I'll get a response from them should I ask 'em to whitelist
medusa.blackops.org and mail.ietf.org so that my emails to the DMARC mailing
lists will get delivered properly.
No sane Receiver would accept such a request from a Sender or Domain
Owner. This was tried, with limited success, some years ago but it
quickly became clear that assessing a Sender's behaviour and
auto-green-listing[1] well behaved senders/forwarders was a better
approach than inviting spoofers to waste a Receiver's time arguing the
point.
Near as I can tell, the only way I can employ a DMARC p=reject for my domains
and still get my messages delivered to inboxes at gmail and Yahoo is to:
a) add hostnames of mailing list MTAs to my domains SPF records.
b) cajole the mail server operators into disabling list footers, so
they don't break DKIM signatures
If every domain owner has to do this for every email list their users subscribe
to, a rather large side effect of DMARC deployment is going to be swollen SPF
records.
Erm, please see any of the _*thousands*_ of messages on this subject in
this list's archives, and DKIM's, and ADSP's, and... Arguing it further
on a public list is not advised. DMARC is not appropriate for domains
which send email to mailing-lists, because of the dilemma that I
outlined above.
You didn't address my suggestion though, why not simply drop Subject:
and body from what you're signing?
- Roland
1: There doesn't yet appear to be a consensus term for this.
"White-listing" is ordinarily understood to mean listing
senders/forwarders whose email should unconditionally reach the inbox;
what we're talking about here is simply deciding when to ignore DMARC.
I'll continue to refer to this as green-listing until a better option
appears.
--
Roland Turner | Director, Labs
TrustSphere Pte Ltd | 3 Phillip Street #13-03, Singapore 048693
Mobile: +65 96700022 | Skype: roland.turner
[email protected] | http://www.trustsphere.com/
_______________________________________________
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)
