On Wed May 11 2005 08:45, Frank Ellermann wrote:
The RFC Editor will hold up publication as an RFC until
all normative references are published.
As long as his queue is really a queue it should work.
I'm not certain, but I suspect that the RFC Editor staff doesn't
sit on their collective thumbs when one document hits a roadblock.
Considering that there are documents in the queue dating to 2002
and there are recent documents emerging with assigned RFC numbers,
I suspect that they move on to other documents.
I've seen your discussions with Dave and Scott on the rfc-
interests list, and thought that all problems are resolved.
No, there are other problems that were mentioned on rfc-interest
but not subsequently; e.g. the unused
3*5[foo]
construct. After some thought, you may realize that that's
equivalent to *5foo (i.e. the first number is meaningless -- it
could be anything, and the brackets as well). Normally when
advancing a specification to Draft status, unused features are
removed -- they tend to result in interoperability problems and
are a ripe source of security exploits. Now nobody is going to
exploit ABNF oddities, but if we have a process for advancement
(RFC 2026), and that process calls for removal of unused features,
then we ought to be following that process. Otherwise, we make
an exception here and another there, and next thing you know
nobody is following the rules.
[2045]
That's EBNF
1*<verbose text> is EBNF ?
Yes, as in RFC 822:
CHAR = <any ASCII character> ; ( 0-177, 0.-127.)
That's a piece of prose in angle
brackets. Yes, I knew the bit about some missing slashes, but
didn't know that it's another case of "erratum lost in space".
Yep. Found it about a year ago when looking at something to do
with USEFOR (User-Agent, IIRC). Doesn't really matter now, I
suppose, as USEFOR has gone so far down a rathole as to be
unsalvageable, and its time has run out:
Apr 05 ReCharter or conclude
the only domain associated with sending SMTP mail is that
which may be specified in HELO/EHLO, when a domain literal
is not used.
That's one domain, as you say maybe. The other domain is what
you find in the reverse path after removing the route and the
local part. Somewhere it all started, from the POV of SMTP,
and that's the responsible party.
No, the path for delivery notifications:
"reverse-path which can be used to report errors" (STD 10)
MUAs are also [E]SMTP clients, and many MUAs do not have the
ability to set the name proffered during SMTP sessions.
MUAs in trouble will find a smart host or an MSA.
My, how blithely you wave away other people's real problems. See
http://www1.ietf.org/mail-archive/web/asrg/current/msg12017.html
And if they'd say "HELO computer" that corresponds to a result
"neutral" in the discussed I-D, because "computer" is no FQDN
and therefore illegal -- see JCK's recent message on ietf-smtp.
which doesn't work because of DHCP, NAT, multi-homed hosts,
and IP-less and/or domain-parked domain names.
No, that's not the idea. In any SMTP session the client has
an IP, logged in the timestamp line. Sometimes it also has a
HELO FQDN (otherwise "neutral" => forget it, see above).
Many times not under the control of the sender.
Caveat, no shortcut, the I-D isn't about IP(client) = IP(FQDN).
For the draft it's only relevant to find an "authentication
policy of some kind". If not found => "neutral" => forget it.
But if you find this obscure policy it will list permitted IPs,
and if the SMTP IP of the client is not in this list => gotcha.
That won't slow down spam, but it will inconvenience many
legitimate senders. It is widely known that spammers are
early adopters of SPF and similar wacky schemes.
There's nothing wrong with this idea.
There's plenty wrong with it; it presumes a specific model
that simply doesn't apply in many cases.
It assumes that SMTP and DNS exist, state of the art STD 10 is
good enough.
It fails to account for legitimate situations as descriped by GEP.
There is absolutely no reason to attempt any sort of
"authentication" of a reverse path domain
Several hundreds of thousands domain owners strongly disagree.
Several billions of bacteria eat feces; that doesn't make it a
good idea for all organisms.
Moreover, that reverse path can be null
We had this already, if there is no FQDN, then there is also no
policy, and the result is "neutral".
And the effect on spammers will also be null.
even though RFC 2821 fails to provide for that case in its
ABNF.
[at the end of 4.1.1.2]
| "MAIL FROM:" ("<>" / Reverse-Path) [SP Mail-parameters] CRLF
That's nice. And when you make "final delivery", what will you
put in the Return-Path field?
for example it has an IP address of 123.45.67.89 and it
responds to the greeting with HELO [123.45.67.89]
Very sane, but no FQDN => no policy => "neutral" => forget it.
You could still reject a domain literal if the IPs don't match,
but that's your decision and no "sender policy". And if you
reject mails you don't need a header field, but an error code.
1) you don't have any "FQDN1"
xyzzy.dnsalias.org
No, in the example.
So a spammer (or collective of spammers) can register any domain
name with no "policy", or simply use domain literals and spam at
will -- no effect on spammers, big problems for legitimate users.
2) there exists no Standards Track mechanism for "defined the
set of IPs used by his MTAs". Not even an Experimental RFC
Dozens of I-Ds
Internet-Drafts are not standards.
have you ever tried to change what your "Mozilla 3.0" uses?
Sure. It assumes that I have an FQDN or get lost.
I suspect you'll find that it uses the RHS of your mailbox as
the HELO domain. Now try taking a laptop with such a client,
with a domain who has a fascist "policy", to an airport courtesy
lounge, an Internet cafe, etc. -- especially one that blocks outbound
port 25 and requires using a local relay.