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.
Receivers already perform a handful of DNS lookups and other forms of
validation upon every inbound connection. Since a Message-ID check would
necessarily be after DATA, it would only be performed on the small fraction of
messages that didn't already get rejected by other filters. If it were a DMARC
authentication test, and it were expensive as you allege, then it could be run
only after other authentication mechanisms (SPF & DKIM) have failed.
> 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. 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.
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.
Matt
> - Roland
>
>
> On 05/24/2013 05:11 AM, Matt Simerson wrote:
>> RFC 5322 states that every email SHOULD have a unique Message-ID. In
>> practice, unless a user has authenticated (in which case, we add the
>> Message-ID, per RFC 5322), every legitimate message arriving via SMTP will
>> have a Message-ID. Right?
>>
>> It seems the only thing lacking for a 99.99% reliable authentication
>> solution is a mechanism for the receiving MTA to ask the purported DMARC
>> enabled sending MTA, "did Message-ID [big.long.unique.id.here] originate
>> from you?"
>>
>> In all the edge cases I can think of where DKIM and/or SPF validation fail,
>> this approach would still work.
>>
>> The sending MTA could implement the Message-ID validation service in a
>> number of ways: as an SMTP protocol extension, a TCP/UDP service, or a
>> special DNS zone. With a special validation service, additional information
>> about the attempt could be captured, in lieu of aggregate reporting.
>>
>> My first inclination is to delegate a special DNS zone to my mail servers
>> and publish Message-ID's in the DNS. Each Message-ID is a DNS name that
>> automatically expires in a week. I have a sufficiently large namespace that
>> false positives aren't a concern. The address portion of the DNS record
>> could be a hash of the To and From headers, deterring Message-ID replay
>> attacks.
>>
>> Is this a practical idea?
>>
>> Matt
>> _______________________________________________
>> dmarc-discuss mailing list
>
> --
> 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)
