On 4/13/15 12:58 AM, Stephen J. Turnbull wrote:
> Douglas Otis writes:
>
> > If the DMARC domain fails to step up, then a reasonable fallback
> > could require the display of the Sender header offering the needed
> > alignment.
>
> I don't understand this. We already see that most professional
> spammers exhibit From alignment on much of their traffic. Sender
> alignment is just as easy to implement, even if we could expect MUAs
> to conform to the "required display of Sender field". Users do not
> understand the Sender field as far as I can tell.
Dear Stephen,
I am writing an I-D expanding on DMARC's disruptive views in
hopes of finding a stable path forward. As an analogy, the
credit card industry outside the US assumes users will
remember their PIN. In the US, often protection depends on
sporadically checked signatures. When less is expected of
users, less protection is afforded.
Email as defined includes the role of Sender. When Sender
is missing, the Author is assumed to play this role. There
are ways to ensure the Sender header is displayed when
aligned with SPF or DKIM records. Blocking valid messages
by ignoring the Sender's role suggests email will not
function as defined.
Allowing DMARC alignment with Sender header fields along
with the display of Sender content ultimately affords users
greater protection. Only in the case where a domain just
issues transactional messages will ignoring Sender header
fields then make sense. Otherwise valid third-party
messages will be placed into spam folders or the Author
identity will be munged in response to Sender header field
limitations imposed by the DMARC domain.
Permitting a clean mode of delivery from a DMARC domain
handling normal mail services should be permitted when
Sender is aligned with SPF or DKIM records. Only by making
an allowance for Sender header fields for normal email use
can Authors be accurately and clearly conveyed. Yes, this
expects users to understand they are primarily trusting the
Sender which should be displayed much like the pad-lock on a
website.
TPA-Label can further increase protection by allowing a
DMARC domain a means to signal established third-party
relationships. This would normally involve a small portion
of the email a DMARC domain might send. Like SPF or DKIM,
TPA-Label would represent an even smaller overhead.
Alternative efforts at creating weak signatures will also
require advanced auditing of DMARC feedback and of outbound
logs while not improving overall protections or providing
more comprehensive coverage.
TPA-Label may appear complex, but the added information
reduces possible attack scenarios and better ensures various
identifiers can be used to cull these messages. It is
assumed these identifiers would result from an audit of the
feedback characterizing what recipients should expect. This
would not be the user telling a DMARC domain anything other
than using the third-party service. TPA-Label is only used
when an exception is to be used to safely handle third-party
services. TPA-Label will not increase the message size or
involve additional signatures.
While TPA-Label may involve tens of thousands of domains,
our feedback was processed in much the same manner
approaching hundreds of millions queried by MTAs world wide
without imposition of a fee because of its slight overhead.
Use of TPA-Label offers greater scalability than domain
lists included in draft-kucherawy-dkim-delegate or
draft-levine-dkim-conditional. Unlike these two schemes,
TPA-Label can impose or permit other options at the
discretion of the DMARC domain. In this case a valid DKIM
signature would be required before excusing a third-party
domain from being subjected to the DMARC policy imposed by
the From domain.
This record would permit isp.com after it adds a valid DKIM
signature. This would provide the same results as would be
obtained by draft-kucherawy-dkim-delegate or
draft-levine-dkim-conditional which must impose their
decision isp.com is okay adding an additional signature.
The possible number of third-party services approved to then
forward the message is limited by the size of a list
supported within the DKIM signature.
There is no such limit for TPA-Label. The argument that a
priori DNS publishing is too cumbersome overlooks the
situation when this represents first use of a third-party
domain where other a priori checks are likely needed as
well. Once a third-party domain is listed, this offers a
low latency lightweight signal to all of the DMARC domain's
MTAs it okay to sign and send, and for others to then
receive a message modified and resigned by isp.com. The
receiver will not need to perform additional signature
checks beyond normal confirmations for messages from isp.com
containing the domain example.com looking up the following
DNS record:
_HTIE4SWL3L7G4TKAFAUA7UYJSS2BTEOV._smtp._tpa.example.com.
IN TXT "v=tpa1; tpa=isp.com; param=d;"
Imposing a specific path that email traverses be defined
prior to the message being sent will ossify SMTP into
becoming a fragile and unreliable process. A cure worse
than the ailment. The goal is not to create a Pachinko like
path for email to follow. The goal is to allow the DMARC
domain a means to quickly mitigate abuse.
Perhaps it should be noted, a common structure of safe
third-party domains could be shared among many different
domains, allowing an organization to specialize in
monitoring and maintaining such a list.
Regards,
Douglas Otis
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
