Re: [dmarc-ietf] Simple authorization offers reasonable control over messaging resources

[Terry Zink <[e-mail]>]

> The Sender header field when present has been defined for
> decades to represent the sending agent!

Maybe, maybe not. Outlook desktop client shows the Sender: header as "<sender> on behalf of <5322.from>", but neither Hotmail/outlook.com nor Gmail do. They just show the 5322.From address regardless of whether or not there is a Sender: header. This Sender: DMARC fix requires a change in the way these clients render email. Given the marginal additional benefit to  receiving mailing list traffic that won't implement any of the published workarounds (not modifying content, fiddling around with Reply-To and From addresses, changing the From: domain to be the mailing list domain), I can't see why Gmail or Hotmail would want to make a change like that. I agree with Murray that it isn't worth pursuing, the cost/benefit ratio isn't there.

> Again, we will happily help any large ESP configure and
> maintain their services to make use of this scheme and even
> offer the needed resources.

Doug, who is this "we" you keep referring to who will happily maintain someone else's DNS zone? Your employer? Are you volunteering them on their behalf? Is this a free service of theirs? If not, why would anyone agree to a solution that is hard to manage at scale but, lucky for you, just so happens to benefit your employer?

The TPA authorization DNS zone publishing has been pushed by yourself and another board participant and has received universally negative feedback, or at best neutral feedback. The people here are smart and have as much experience as anyone else and they understand what you are saying. But they still don't agree, including me. I think it's time to make like the movie Frozen and let it go.

-- Terry

-----Original Message-----
From: dmarc [mailto:[e-mail]] On Behalf Of Douglas Otis
Sent: Thursday, May 14, 2015 4:06 PM
To: [e-mail]
Subject: [dmarc-ietf] Simple authorization offers reasonable control over messaging resources



On 5/14/15 4:54 AM, Murray S. Kucherawy wrote:
> On Thu, May 14, 2015 at 12:51 AM, Stephen J. Turnbull <[e-mail]>
> wrote:
>
>>  > What gets added from here forward really needs to be as innocuous
>>  > as possible.  I believe we're in a position where things like SPF
>>  > and DKIM are still young enough that their implementations are
>>  > malleable,
>>
>> I'm not sure what you mean.  Now that I actually know what those
>> protocols do (and DMARC itself, for that matter), I don't really see
>> how they can be much improved.  Do you mean the policy engines that
>> make decisions based on the output of SPF and DKIM implementations?
>>
> I'm saying that incremental changes to DKIM, SPF, and DMARC are far more
> likely to succeed than anything along the lines of "Everyone start using
> and paying attention to Sender", "Let's register yet another Sender-type
> field", or "Registration scheme X".  The operational changes required for
> those three families of solutions are too enormous and involve too many
> wildcards for me to believe they stand a chance of success.
Dear Murray,

The Sender header field when present has been defined for
decades to represent the sending agent!

DMARC improved delivery registration accuracy for
TRANSACTIONAL messages based on the SMTP MailFrom parameter
(bounce address) or DKIM (unrelated to any field) where
either is allowed to fail.  For TRANSACTIONAL email,
combining these two marginal authorization schemes easily
adjusted to relate with the From header field offered a low
percentage authorization failure to better ensure compliance
with a restrictive policy.  The expediency this allowed did
not justify disrupting valid and legitimate exchanges not
limited to transactional or direct messaging configurations.

Neither DKIM nor SPF authenticate an actual message source,
but simple authorization offers reasonable control over
messaging resources.  DMARC is fine when messages are
limited to direct exchange, but fail badly when exchanges
make use of the Sender header field that may signify use of
mediators or other resources.  At one time DMARC even
recommended against issuing non-transactional messages, but
acknowledgement of DMARC's potential disruption of normal
email interchange was dropped.

Commercially available products for years have been able to
clearly indicate the entity trusted at providing a message. 
It seems DMARC assumes recipients are too easily misled and
can't be trusted to deal with S/MIME, OpenPGP, or MUAs that
verify and display the Sender header field and think
everyone is better able to deal with munged From header fields.

The TPA-Label is able to thwart wildcards simply by
publishing a negative wildcarded label.  A practice that
won't work with DNS-SD.  A sender must have reasonable
control over the resources they authorize.  Any double
signing scheme relaying authorization to a third-party via
DKIM can not control the authorized resources since the
entire message body may change and DKIM can be replayed to
any destination by design.  Without adequate control,
authorization protections fail simply because neither SPF or
DKIM are able to authenticate the source, nor can DKIM offer
an expedient authorization retraction in say a 5 to 15
minute range.

While I commend efforts made at fleshing out your version of
the ATPS protocol, due to the inherent hurdles introduced
for third-parties it was unlikely this scheme would be
adopted.  The lesson is DKIM offers a poor method to signal
changes beyond those already expected.

There was no reason to change how a third-party is verified
since they too can use DKIM and SPF or even DANE or the HELO
parameter for that matter.  The correct place to signal such
change is at the DMARC assertion.

See Third-Party Authorization example of:

"sam=tpa; and tpa=third-party-authority.example.com;"

https://tools.ietf.org/html/draft-otis-dmarc-escape-02#section-4

This scheme involves a simple DNS server operating an
isolated zone separated from other domain services and can
even be published by a different domain.

This approach allows the _tpa zone to be maintained as a
community effort or as a specialty service to ensure the
sender has reasonable and nearly immediate control over the
resources they authorize.

By being able to include policy for the Sender header field,
DMARC can become compatible with RFC5322.

While some might describe this a complex authorization
scheme, it can be combined with
<https://tools.ietf.org/html/draft-levine-dkim-conditional-01>
draft-levine-dkim-conditional to offer a resource record
where only the base portion of the domain might be included
to guard against domain hash collisions.

TPA-Label that had the goal of reducing collateral damage
caused by compromised accounts or resources, can be combined
with draft-levine-dkim-conditional to signal when this
limited signature should be included and which domain needs
to be authorized.  Because this uses very simple resource
records, is should scale far better than SPF and yet permit
a means to establish an informal federation scheme to better
protect email infrastructure with low latency abuse responses.

TPA-Label does not make handling third-party messages
harder.  Instead, TPA-Label offers a simple way to signal
which domains require exceptional handling.  Without such a
feature, DMARC can not be seen as being compatible with
RFC5322. 

Again, we will happily help any large ESP configure and
maintain their services to make use of this scheme and even
offer the needed resources.

Regards,
Douglas Otis


_______________________________________________
dmarc mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dmarc