Some quick comments:
- Section 3 is really short. Some examples of how it would work would be nice.
- Regarding this from section 3:
This makes an assumption users employ Mail User Agents that display the
identity contained in the Sender header field when used as a basis
for acceptance.
I've tested Hotmail and Gmail and both suppress the Sender: header in favor
of the 5322.From address. Conversely, Outlook and Outlook Web Access (OWA) show
it as "<sender> on behalf of <from>".
-- Terry
-----Original Message-----
From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Douglas Otis
Sent: Tuesday, April 21, 2015 4:10 PM
To: dmarc ietf
Subject: [dmarc-ietf] Dmarc-escape draft available
Dear WG,
A draft has been posted offering two alternatives not
requiring cooperation of disruptive ESPs.
Basic unilateral escape methods include use of a From
replacement header IM-From:. This header can include the tag
normally added to the Subject line as the display name in
the Group syntax. It also includes a placeholder for
resource connection used in a "live" discussions, hence the
use of IM. This header is free to carry the author role
since it will not be excluded by DMARC policy. The other
unilateral mode is to defined a DMARC fallback policy 'p'
for public user accounts. This mode permits acceptance
based on the Sender header field alignment with assumed MUA
displaying the identity sourcing the message.
It also attempts to remove concerns related to adoption of
TPA-Label from the perspective of large providers by
allowing DMARC policy to indicate a consolidated tpa-label
zone rather than being directly accessed from the customer's
zone. This avoids use of DNAME or zone delegations.
While TPA-Label may appear to contain too much information,
all of it is optional. The goal behind providing a structure
for additional third-party information is to allow
anticipated limitations be imposed on the scope of
authorization granted. This scope also selectively permits
other authentication methods be accepted beyond just DKIM or
SPF. It is able to indicate the message must be DKIM signed
AND must contain a specific LIST-ID header, for example.
This ensures recipients in this domain can depend on safer
sorting of disparate messages sources from the same domain.
http://tools.ietf.org/html/draft-otis-dmarc-escape-00
Regards,
Douglas Otis
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
