spf-discuss
[Top] [All Lists]

Re: [spf-discuss] 2821bis email museum (was: Statement of Problems and Requirements (Last Call))

2008-02-11 14:17:03
Frank,

Thanks for your attached information. Perhaps Dave can look at mapping the relevant 2821bis terminology into his current work, if it fits and makes sense.

As I said before, I think that Dave is working to reach a set of common terminology which most can agree upon to illustrate any of the valid concerns regarding SPF and from this work to find good solutions or at least to minimally address the concerns adequately.

I do agree with other members that we probably should not invent new terminology which replaces accepted existing terminology. What Dave seems to be working toward looks like a worthy goal, so if we can get existing terminology to work within the framework of what Dave has in mind, all the better.

Best,

AlanM
The Commerce Company
TZ.Com - Travel Zippy

At 07:15 AM 2/11/2008, you wrote:
Alessandro Vesely wrote:

> IMHO, the confusion stems from the IETF having apparently lost its
> ability to specify standards. One may wonder why rfc2821 explains
> relaying with examples grabbed from the email museum, like so:
[...]

2821bis is supposed to be better.  I've just checked all occurences
of "forward" in 2821bis-08 and think they are consistent, reflecting
what Scott said:  2821bis limits "forward" to the numerous cases of
<forward-path>, forward-path, and a single forward path (that might
be a typo) *PLUS* "forward" in the sense of "change RCPT TO, but not
MAIL FROM" *PLUS* "forward" in and out of the Internet at a gateway.

The <forward-path> construct is what you call "email museum", and
all proposals to remove the source route cruft from 2821bis did not
make it.  In that "email museum" (or RFC 821) a non-delivery report
was sent by transforming the reverse-path with all hops so far into
a new forward-path with a new empty reverse-path.  Maybe that was a
kind of relay = forward synonym.  IMO we can ignore this today, and
2821bis never confuses "forward" and "relay".

What gateways do is mainly irrelevant from our POV, but if the other
side also uses SMTP with its own private non-Internet addresses it
will certainly change the RCPT TO (and also change the MAIL FROM, so
that's perfectly sane from our POV, it is also okay in RFC 1123).

And the last case "forward" or "deliver" after changing the RCPT TO
without changing the MAIL FROM is precisely what we want.  2821bis
uses the term "redistribution" when both are changed, that's again
sane (and therefore irrelevant) from our POV.

> Is the IETF becoming the Internet Museum?

Ignore the routing cruft.  It is only interesting in SPF discussions
explaining *why* forwarders were *not* supposed to change *only* the
RCPT TO in RFC 821, because there relays (not limited to forwarders)
were expected to add their FQDN to the reverse-path.

After RFC 1123 deprecated this feature that's "archaic" as RFC 4408
put it, introducing SPF to emulate it as good as possible today. ;-)

The 2821bis Last Call ended weeks ago, and the move to "decruft" it
was unfortunately not strong enough to convince the author.  If we
get a second chance we could try again - but if you dig through the
list here you'll find that my original proposal was to have a kind
of "email museum" memo *ready* before a revived 2821bis effort.  But
nobody did this (notably not me), and the author decided to try it
again without IETF WG based on his old (2005) 2821bis-00 draft.

At some points authors need to go with what they have, and "make a
shorter draft" was not among the Top 10 wishes for 2821bis.  I'm not
too happy with 2821bis, but for this issue I think it is not John's
fault, splitting 2821 would take much more work than only fixing it
within the limits of a promotion to "draft standard".  That is what
he wanted, and only one contributor (again me ;-) was unhappy with
this artificial limitation.

My two cents in defense of the IETF,

 Frank

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?&;
Powered by Listbox: http://www.listbox.com


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription: 
http://www.listbox.com/member/?member_id=2183229&id_secret=94778097-cc7d45
Powered by Listbox: http://www.listbox.com

<Prev in Thread] Current Thread [Next in Thread>