On Monday, June 09, 2014 22:38:54 Barry Leiba wrote:
> >>Putting as much value on RFC5322 From as DMARC does follows
> >>conventional wisdom, but I believe that wisdom is flawed.
> >>
> >>Of course, that speaks to the advice you want to give: tell UIs that
> >>they should show the From addr-spec to users always.  But be clear
> >>about what you're asking for: you're not saying they should do it
> >>because it's objectively "right"; you're saying they should do it
> >>because it helps support the decision that DMARC has made.
> >>
> > If any authentication technology is going to work, DMARC or whatever,
> > it will have to be tied to some kind of identifier.  5322.From is as good
> > as any and better than most.
> 
> And yet SPF uses a different one (5321.Mail.From), and there've been
> suggestions to use Sender, rather than From, if Sender is present, or
> to check both.  There's no one "right" answer, and all have failings.
> 
> If a spec is going to suggest UI changes to match the choices that
> spec has made, it needs to be clear about where those suggestions come
> from.  And the people making the recommendations need to understand
> that their recommendations might be wildly in conflict with what UI
> experts know to work best for users.

When developed, SPF had a different design goal, bounce reduction.  Any anti-
phising/anti-spam benefit was really a side effect.  No U/I exposure was needed 
for it to be successful.  You've got to hang your hat on one identity.  The 
wild market success of Sender ID is possibly instructive of the implications 
when you don't.

As has been discussed more than one time, if you allow Sender and From, then 
arbitrary Sender's can send mail that will pass with an unverified 5322.From 
(either the address or maybe just the pretty name) being all that's displayed 
to the end user.

Perhaps I'm oversimplifying, but it has seemed self-evident that you need a 
single identifier that is displayed to the end user and 5322.From is the only 
identifier that even comes close to being the right one.

Scott K

_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to