Re: Enough RE: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Keith Moore wrote:
 
> It's a perversion of RFC 822 which contradicts both the
> intent and the way it has been used in practice.

It's probably clear that I hate PRA, because it's a kind of
FUSSP (worldwide "add Resent-Sender" at places where that
was never before required), because it claims erroneously
to be normally (default) "compatible" with Return-Paths
covered by a v=spf1 policy, and because it does not even
_reference_ 2476bis, let alone discusss 2476bis 8.1 details.

But I don't see where it's a "perversion of 822", IIRC the
author was present when it was evaluated in a MARID chat -
more than a year that I read the jabber log, I'm not sure.

If I get a mail Resent-From: C, Sender: B, From: A+B, then
822 tells me that A+B were the authors, B was the sender,
somehow C got it and resent it to me.

And if I then want to ask "why did you send this to me?",
I'd send that question to C.  I don't need any "license" or
draft-lyon-senderid-pra for that task, but C is the "PRA",
the address claiming to be the sender.

So far no problem in _that_ draft.  It could be a PS, if
they'd add some considerations for say mailing-lists.  But
they say that mailing-lists and other redistributors MUST
also use that Resent-scheme in draft-lyon-senderid-core,
that's the point where senderid degenerates into a FUSSP.

But the "algorithm" itself to find an address of the last
entity claiming to be the sender of a mail (excluding all
"mediators" like mailing-lists on behalf of the receiver)
is sound.  The recommendation that MUAs should display
that address is IMHO also okay (and maybe stuff for a PS).

Otherwise this PRA "algorithm" is only "informational",
it could as well be published as one of many answers in a
mail header FAQ.  Nothing in draft-lyon-senderid-pra is
"experimental".  It just reflects what (2)822 say about
Resent-From, Resent-Sender, Sender, and From.

So yes, the authors read and understood (2)822, and while
they were at it they published a summary of their findings
as draft-lyon-senderid-pra.
                             Bye, Frank



_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]