ietf-822
[Top] [All Lists]

Re: I-D ACTION:draft-kucherawy-sender-auth-header-02.txt

2005-05-11 05:54:50

Bruce Lilly 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.  They
have already identified the queue delay as major issue on the
general list, let's see how they fix it.  For "they" read
e.g. the articles by Margaret, and if Bill and Scott team up
to discuss this with the RfC editor I can only hope that his
last will is up to date.  The "new errata" procedure is also
not yet convincing.

there are some serious problems with the ABNF draft
(admittedly also in 2234):
http://www1.ietf.org/mail-archive/web/ietf/current/msg34855.html

I've seen your discussions with Dave and Scott on the rfc-
interests list, and thought that all problems are resolved.

I don't see a "serious" problem in your article, some typos,
a nice to have non-essential idea how to improve comments -
which might be not backwards compatible, and who cares about
the semantics of standalone comments - and something about
CrLf on the IETF ftp-server, as far as I'm concerned that's
an issue of the ftp-server, not in 2234bis.

Any hint in the direction of [CR] LF instead of CRLF is IMHO
_dangerous_ - and I'm not talking about some angry MAC users
wanting (( CR [LF] ) / ( [Cr] Lf )) instead of [CR] LF.

For a nitpicking contest I'd submit LWSP = *(WSP / CRLF WSP)
together with "strongly advised to use grouping notation".

 [2045]
That's EBNF

1*<verbose text> is EBNF ?  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".

3834 does refer to 2045 and does not attempt to redefine
"token" as an empty rule.

ACK, that was my real question, how to import terms defined
elsewhere.  And "token" can't be imported from 2045, see above.

For terms redefined by RfC 2231 I'd prefer rocket science ;->
It's been done.

Keep your implementation, it's desperately needed when they'll
ever try to find two independent RfC 2231 implementations. <eg>

 [1958] 
Informational RFC written by the IAB, not FYI.  It addresses
the end-to-end issue.

Not in conjunction with the MX concept in SMTP.  It addresses
also KISS, and the RMX idea is pure KISS.  Never mind that the
really existing incarnations of RMX are more baroque than KISS:
In essence it's still the same simple idea, publish mailouts.

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.

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.  Otherwise I
don't care about their fate if they try to send direct-to-MX.

And if they'd say "HELO computer" that corresponds to a result
"neutral" in the discussed I-D, because "computer" is no FQDN
with an "authentication policy of some kind".  Dito any domain
literal.

the MTA identification *is* the domain used in HELO/EHLO.
Unless of course you try to tie that to IP addresses

Yes, that's the idea, you will have some difficulties if you
try HELO xyzzy.claranet.de

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).

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.

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.

There is absolutely no reason to attempt any sort of
"authentication" of a reverse path domain

Several hundreds of thousands domain owners strongly disagree.

Including mere catch-all vanity domains like "my" @xyzzy.  I've
had more than enough bogus "bounces-to", about 1000 per day for
six months.  The "bounces-to" concept is _criminal_ negligence.

There are terabytes of reasons.  And THAT is an architectural
question.  Voluntary and KISS, you can't demand more.  Fixing
real bugs etc. is all fine, but the essential idea is sane.

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".

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

As noted, the draft needs a great deal of work before it can
be reviewed thoroughly.

Here we agree, it was about the first thing I said on mxcomp
(the former MARID list) when the -00 version was published.

Something with the boilerplate to create this I-D is odd, e.g.
the "Table of Contents" is empty.

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 smtpd, no sender policy, but in theory)

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, the discussed I-D doesn't list them.  One of
these I-Ds is very stable and more popular than say RfC 3865.

3) IPs change, due to DHCP among other reasons

Yes.  One of the reasons why they've invented DNS.  It's not
necessary to be precise, you can use names and/or CIDRs.  You
can even permit all IPs excluding some IPs.  As dynamic as you
wish.  And if you don't like it just don't participate, it's a
voluntary system.

have you ever tried to change what your "Mozilla 3.0" uses?

Sure.  It assumes that I have an FQDN or get lost.  And it also
assumes that I have one or more smart hosts (today we'd say
MSA, but my monster is too stupid for this idea).  But it's my
monster, I love it, I know how to use it, and it never talks
to strangers (= any MX) without my permission.  It's always on
the "ours" side of business, no crash mail, this isn't Fidonet
or UUCP.
                             Bye, Frank