On 4/12/15 8:02 PM, Stephen J. Turnbull wrote:
Scott Kitterman writes:
> Yeah. I don't think it's possible to allow sending by arbitrary
> 'authorized' third parties without also making it possible to allow
> sending by anyone.
I don't know how you'd go about authorizing the third party and
validating the authorization, but AFAICS an authorized sender, with
that address in the Sender field and DMARC-but-with-Sender-Alignment,
does for third parties what DMARC does for first parties in From.
(Cue Douglas Otis pitching draft-otis-tpa-label and Hector Santos
pitching some policy framework with authorization via DNS, but I don't
think that auth-by-DNS scales to humongous mailbox providers.)
Dear Stephen,
The TPA-Label scheme can signal new requirements,
such as John's suggestion for a new browser
authorization scheme.
With respect to auth-by-DNS, SPF already does this
for outbound IP addresses. The reason MAPS was
acquired was to leverage DNS to reduce processing
overhead essential for malware scanning. Back
then, we were answering queries from about 70% of
the world's MTAs and were processing about 5
million logs/sec. SQL could never handle this
load on a single server. Custom routines were
written in C doing heap or Judy sort before
transferring to zones.
Our normal deployment supported a free service.
TPA-Label on the other hand would only need to
handle a tiny fraction of the mail volume
requiring a DMARC exception. Unlike the various
DKIM signing schemes that attempt to predict the
needs of the next hop, the TPA-Label scheme can
separately accommodate all possible sources and
distribution patterns while giving the DMARC
domain an opportunity to quickly block abuse as
determined by DMARC feedback which should address
concerns related to this category of email.
Requiring a signing process to guess the needs of
the next hop will be wrong fairly often and ossify
email into becoming more fragile and less reliable.
The TPA-Label scheme could also permit incremental
deployment of the next greatest thing without
being tied to some potentially prone technique
while also affording better message processing
information. Message-IDs can help establish a
path a message takes through various third-party
services, and to identify where problems exist.
No scheme is able to function when administrators
fail to communicate, where TPA-Label offers
actionable and authoritative input.
If the DMARC domain fails to step up, then a
reasonable fallback could require the display of
the Sender header offering the needed alignment.
That said, I am also working on plan B.
Regards,
Douglas Otis
> > >2. Enables third parties to send arbitrary content that will
> > > pass (yes, this is the point, but it's also a negative to
> > > some degree). ...
Sure. So are the ads that some providers post on their webmail
clients, and is allowing first parties to send mail at all. (I wish
my employer would stop, or at least slow down, for example.) I really
don't see how unwanted content from *authorized* 3rd parties can be
considered to count against these proposals. If the recipient doesn't
like it, they revoke the authorization; problem solved.
> For replay protection, I think the Message ID could work, but I
> think the list would have to change to use its own Message ID
> associated with its signature.
You can have your cake and eat it, too. The list can sign a
Resent-Message-ID (as well as the original if it wants to).
> The need to keep and consult a database of historical Message IDs
> does add a substantial negative in my book.
Not if you do it already, and many MUAs already do or have an option
to do it.
Remember, anti-spam measures don't have to be perfect, they just need
to make the mischief unprofitable.
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
