On 6/9/2014 10:38 PM, 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.
+1.
What is an UI expert? I have at least 4-5 MUA products, tools, under
my belt; text-based, native gui-based, web-based, API-based, etc, a
tremendous amount of consideration is made in how/what is displayed to
the user, bells and whistles, and you know what, you can do a great
job, and its still not perfect. In fact, sometimes the best thing to
do is to do less, following Pareto's principle works very well. Take
a look at some of the current reinvention simple ideas for
communications fall back to the basic UI simply to make it "fit to
print/display."
There are two parts to this identity:
- using it as an strong anchor for domain policy,
- using it for displaying to the user.
At the end of the day, its about consistency, and what we are talking
about is basically what will be passed to the mail readers. For the
IETF, its about 822/2822/5322 and the different mail access portals.
We have currently within the IETF; POP3, NNTP and IMAP. Afair, there
is no IETF RFC for a web-based Mail Access Protocol Inteface ("MAPI").
If we have control of the backend, you can do all sorts of things, but
ultimately, what is the goal here?
- Backend filter the message for the user, don't pass it?
- Pass it with highlights?
If the user has a conference based MUA, like the old MAPI exchange,
IMAP, or even Newsreaders, then you can move non-rejected bad mail
into special folders the user still has access to.
If the user only has POP3, then the backend has to decide to filter
the message unless it knows the MUA will be filtering it.
Anyway, one of the central "battles" if we want to call it a battle,
is the philosophical differences about what is to be done with
"rejectable" mail. 5321 finally recognizes the probability of
discardable mail, that was due to the pending ADSP proposed standard
that would of provided technical authorization to operating in this mode.
Yet, there are still folks here that believe that rejecting mail at
SMTP is a "fantasy" not a "reality" and that all mail is always passed
to users.
I say, we are only dealing with the indeterminate mail, the relaxed,
the "half-failed", the mail the backend can't make a decision and
needs to just forget about it and pass on. The hard failures are
really not a problem. They may have some False Positive yield, but it
is extremely low to non-existence (set it and forget it).
No, instead we are fighting, wasting so much time, about what to do
with highly detectable rejectable mail based on a policy system.
I go back to RFC5016, where at the last minute, this itemized section
5.3 provision was added:
10. SSP MUST NOT provide a mechanism that impugns the existence of
non-first party signatures in a message. A corollary of this
requirement is that the protocol MUST NOT link practices of first
party signers with the practices of third party signers.
INFORMATIVE NOTE: the main thrust of this requirement is that
practices should only be published for that which the publisher
has control, and should not meddle in what is ultimately the
local policy of the receiver.
Refs: Deployment Consideration, Section 4.3.
We still haven't gotten over this hump. I had warned backed then this
would be a conflict and it was never was resolved. That MUST NOT is
still a strong influence, especially among the LSP (List Service
Provider) who feel threaten by strong Author Domain policy protocols.
Its a fundamental concept that if a DMARC WG was started, it would
have to be revisited because if the above concept is still applicable,
then I have a hard time seeing any resolution to any of this.
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
