On Mon May 23 2005 04:23, Frank Ellermann wrote:
Bruce Lilly wrote:
the draft attempts to document a version which has apparently
been superseded.
No, that's not the case.
I said "apparently", and that's based on registered IESG comments:
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12662&rfc_flag=0
If the intent is in fact to change the intended status from
Experimental (I-D tracker) to Standards Track (as stated by
the author in the predecessor of this message; see below)
Yes, TTBOMK that's the intent (in fact I'm almost sure, I've
seen the unanimous resolution of the SPF Council).
Ooh, a "Council". Not an IETF WG. Not a recognized SDO. I'm
not impressed. I'm giggling. Was that the intended effect?
Anyway, the intended status is an important issue. Other than
Experimental documents, when there is no clear consensus on similar
competing methods to do essentially the same thing (and in the case
of this subject matter, all making essentially the same errors), the
IETF and IAB generally don't like specifying multiple incompatible
ways to do the same thing; see RFC 1958, but note that extensible
protocols such as those which provide multiple message digest
algorithms within a single protocol framework are a subtly distinct
case. The author's statement was that he wished to document
something and he appeared to be adamant that no changes to the
specification would be entertained. That would be an Informational
document. Standards Track is another matter, and has been discussed
in a previous message. It doesn't seem to be a viable option.
Use of the word "standard" is going to cause problems
ok.: | standard dotted-quad format.
At minimum, needs a normative reference. Is it supposed to include
or exclude the brackets which are used in email contexts (RFCs 821,
822, 1123, 2821, 2822)?
ok.: | time() function in most standards-compliant libraries.
Refers to POSIX, an external standard. Raises questions about
implementations. N.B. there are many non-POSIX hosts on the Internet.
Is the specification intended to exclude such hosts from using the
specification?
ok.: mail header registration form | Status: standard
Not OK for an Experimental or Informational RFC, nor for something
which is obsolete or harmful.
ok.: ipr=full3978 IETF boilerplate | this standard.
IESG/IAOC/IPR WG's problem. Whether or not it's OK depends on the
usual relevant issues ("whether the said cow were red or
black, her horns long or short, whether the field I graze her in be
round or square, whether she was milked at home or abroad, what
diseases she is subject to, and the like" [*]), and I suppose we
can expect the problem to be resolved in due course ("in ten, twenty,
or thirty years" [ibid.]). But I digress...
The MAIL FROM argument specifies a return path for
delivery-related notifications.
Already discussed on the 822 list, I quote the relevant part:
|> "reverse-path which can be used to report errors" (STD 10)
|
| Yes, it "specifies who the mail is from", "a return route (which
| may be used to return a message to the sender when an error
| occurs with a relayed message)", "contains the source mailbox",
| "a reverse source routing list of hosts and source mailbox",
| "a source route from the current location of the message to the
| originator of the message)". Finally "send it to the originator
| of the undeliverable mail (as indicated by the reverse-path)".
|
| Want more ? I skipped some less CLEAR "should", but when I said
| *_criminal negligence_* about any "bounces-to" I was NOT joking.
You pick your STD 10 cherries, I pick mine, shall we count ?
You're:
a) confusing *typical* cases ("who the mail is from") with the
underlying assumption in the draft scheme that that is *always*
the case -- it is not, and that erroneous assumption (coupled
with an unworkable attempt to tie it to a set of IP addresses)
is a fatal flaw.
b) ignoring the fact that, as explained in some detail, the MAIL FROM
argument is passed unchanged from one MTA relay to another during
transport; each relay has a different IP address, and the specific
path is in general unpredictable in advance. Another fatal flaw.
c) ignoring the problem that the assumption conflates sending with
receiving (of delivery notifications). A third fatal flaw.
d) quoting a twenty-year old document which was written in reference
to a network topology that no longer applies, and which has been
obsoleted by a newer document (RFC 2821) that (presumably
intentionally) does not include many of the phrases which you have
quoted.
e) quoting phrases (e.g. "source mailbox") which are devoid of meaning
("A mailbox receives mail"; a mailbox does not "source" mail).
Indeed, a null path is required in some cases to prevent
damaging mail loops.
Addressed in the draft.
As noted, begrudgingly and partially addressed. No mention of
what happens if EHLO/HELO is a literal or unqualified or NXDOMAIN
*and* MAIL FROM is null -- the draft says to consult MAIL FROM
(see flaws above) in the assumption that there is always something
relevant there.
There's also no problem with say "creative" HELOs like my MUA
claiming to be "xyzzy", because there's no FQDN "xyzzy", and
my MUA talks only with its smart hosts, not with arbitrary MXs.
What happens to work for you is
a) not necessarily applicable Internet-wide (and therefore
unsuitable as an Internet Standard)
b) non-conforming (SMTP *REQUIRES* an FQDN or address literal),
and therefore unsuitable as a basis for an Internet Standard)
Skipping some cases where domain owners
The concept of "domain owners" as it applies to the assumptions
in the draft is another set of fatal flaws. All mailboxes (N.B.
"a mailbox receives mail", it does not *send* mail) contain a
domain name. Domain names may be registered, and a domain name
is assigned to (not "owned" by) a registrant. Receipt (but not
*sending*) of mail is tied to a domain name by DNS MX RRs. While
the domain name "erols.com" is assigned to a particular registrant
who operates SMTP receivers and publishes MX records to appropriately
direct mail for the purpose of *receiving*, neither that domain name
nor the registrant necessarily has anything whatsoever to do with the
*sending* of mail which happens to specify a mailbox with that domain
name for *receipt* of delivery notifications. In particular, no fixed
set of IP addresses is associated with the sending of such mail;
while mail is sent (*if* sent "with" SMTP "via" TCP) by an SMTP client
which has an IP address, it is in no way sent "from" a domain, nor is
any relationship between sending mail and a set of IP addresses in any
way specified by SMTP or any related Internet Standard.
As noted in some detail above, the described mechanism is
incompatible with SMTP as standardized, widely deployed, and
used for mission-critical purposes by an extremely large and
diverse community of users on the Internet
That's not the case. Domain owners
Bzzt. Fatal flaws. see above.
Any mechanism which shares those characteristics
(favorable to spammers, harmful to legitimate users) is
doubly harmful to the email system.
Spammers are indeed the only non-volunteers in this mechanism,
it's just working as designed. They can't forge protected
addresses anymore without losing parts of their "audience".
There is no "protection", only
a) a false air of legitimacy, used by spammers
b) damage to legitimate users of the mail system, including but not
limited to mobile users.
---------
* Gulliver's Travels, 1726. Some things never change. Unfortunately.