This would impose an immense burden on receivers and, therefore,
wouldn't get out of the gate.
A simpler scheme which would impose little/no burden on receivers would
be to add an additional DKIM signature signing only the Message-Id (or
to do so instead of signing other parts of the message). You'd gain the
same level of protection at far lower cost, but as John points out, this
protection isn't much. You'd create something which provides no
protection at all from spoofing; spoofers would simply take the
Message-Id (and any related headers) and DKIM-Signature from any valid
message and include them in their spoof. Equally you could DKIM sign all
of the typically signed parts except for those which lists tend to alter
(Subject, body, ...), with the same lack of protection.
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.
- 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
[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)
--
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)
