[Top] [All Lists]

Re: CBV systems - was Re: SMTP Extensions - proper peply code for disabled commands

2004-01-16 10:37:21
On Fri, 16 Jan 2004 11:28:44 EST, Hector Santos 
<winserver(_dot_)support(_at_)winserver(_dot_)com>  said:

For example, if the ASRG efforts finally put out the official
recommendations (which to me, looks like its DNS lookup based, hence sender
machine),  then this along says that it will be conflictive with the current
HELO/EHLO functional specifications. For example,  the following RFC 2821
will now be inconsistent with the IRTF drafts:

So we stick an 'updates 2821' on it.  Isn't like we haven't done THAT with a
number of protocols in the past.

 A server MAY refuse to accept a message if the verification fails, however, 
  non-acceptance of mail failure SHOULD be based on a SENDER MACHINE
  validation technique.  The information about any verification  failure 
  recorded for logging and tracing.

And language like this is *exactly* why the Protocol Police are very leery of
this kind of change.  As currently written, you are NOT allowed to reject based
on the contents of an EHLO - the most you can do is (optionally) warn/log it.

As written, a mail server would be allowed to reject a message, and not explain
to the sender *why* - you're missing a 'If a message is rejected, the server
MUST include an explanatory text in the 5xx reply'.

Also, you're neglecting a VERY important corner case - one of your OWN users
has egregiously misconfigured their machine, causing your mail server to not
let them send a "how do I fix this" to somebody.  You forgot to add language
saying that mail to POSTMASTER must always be allowed through.

Of course, this means that you can't reject at the EHLO, you have to wait till
the RCPT TO: stage - or possibly DATA (and then you get to find out how many
end users are running crapware MUAs that don't know that anything other than a
354 response to DATA is possible ;)

(Incidentally, exactly these sort of bogosities are why the spec didn't allow 
based on EHLO in the first place.)

Attachment: pgpd4Sz5Pfb5x.pgp
Description: PGP signature

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