[dkim-dev] [ietf-dkim] Authorizing List Domains

[Murray S. Kucherawy]

> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Douglas Otis
> Sent: Monday, September 27, 2010 4:19 PM
> To: ietf-dkim at mipassoc.org
> Subject: Re: [ietf-dkim] Authorizing List Domains
> 
> > I don't really want to conduct an experiment that includes myriad
> > optional policy specifications without some operational data to suggest
> > they stand a chance of adoption.  Simpler is better.
> 
> Agreed, but not having a defense against trivial exploitation of an
> authorization is not better.  When a defensive requirement proves
> unused, it can be removed without impact.  Since this information sets
> authorization requirements, adding the information at a later date
> would not be compatible with existing implementations.

That seems antithetical to the idea that this is all experimental work, explicitly not on the standards track.

> Perhaps we can work on the bare essentials independent of the notation
> used.
> 
> Types of authentication that might be used for existing third-party
> services-
> 
>   1) DKIM
>   2) TLS
>   3) SPF
>   4) EHLO/ADR

I wasn't aware we were scoping something intended to be universally used.  My focus has been strictly on DKIM.  Other than TLS, we're not talking about particularly strong authentication systems here so I'm not sure we should spend the cycles to be that accommodating.  However, as I said before, decoupling ATPS from ADSP is a trivial matter if that turns out to be the right way to go.

Since any client can say anything it wants for an EHLO parameter, why should it be considered a type of authentication?

> Additional header field requirements ensure message sorting or
> presentation.  The header field requirement is to offer simple tactics
> against most phishing exploits:
> 
>   a) Sender
>   b) List-ID

Why would one base any kind of security mechanism on a trivially spoofed header field?

> The most visible name to recipients is the domain
> found in the From header, whether used as a basis for sorting, or when
> displayed in addition to that of the friendly name.

Then why create semantics around other fields?