Subject: Re: List of ESMTP extensions
From: Paul Hoffman / IMC <[email-masked]>
To: [email-masked]
Date: Tue, 14 Apr 1998 17:37:47 -0700

I've now updated the Web page for this mailing list at
<http://www.imc.org/ietf-smtp/> to include the list with the corrections
from the list. Let me know if you see other changes needed.

Also, Dan's survey of number of publicly-accessible servers at
<http://pobox.com/~djb/surveys/smtpextensions.txt> is about a year old. Has
anyone done a similar survey recently? It would be interesting to compare
the results over a year.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: 13 Apr 1998 22:42:20 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: List of ESMTP extensions
Sender: [email-masked]

Jack De Winter writes:
> Well, seeing as we are supposed to be writing software so that people
> can use it, and there is and was a need to support transient connections
> that wanted SMTP access, I dont think 'absurd' should be applied to ETRN.

ETRN is very badly engineered. The fact that it works for some people
doesn't mean that it's cost-effective.

Putting ETRN on port 25 made it unnecessarily difficult to implement.
The same function can be (and normally is) achieved through a separate
TCP port---with a much simpler syntax, and a much simpler server that is
implemented separately from the SMTP server. In the long run, merging
ETRN with SMTP slows down the evolution of both services.

> However, seeing as everytime I have tried to check one of Dan's web pages
> (with the plethora of information that is supposed to be stored there) and
> I get an extended error and no web pages back from the server, I really
> dont put much faith in those opinions.

Perhaps you should try Netscape, instead of a second-rate browser that
doesn't understand how to use the standard FTP commands.

---Dan
Smaller, faster, safer than inetd+tcpd. http://pobox.com/~djb/ucspi-tcp.html

Date: Mon, 13 Apr 1998 11:36:09 -0700
To: Paul Hoffman / IMC <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: List of ESMTP extensions
Cc: [email-masked]
Sender: [email-masked]

>Greetings again. IMC is going to be putting up a list of known ESMTP
>extensions, and I wanted to do a sanity check before I posted it on the Web
>site. If you don't see one below for which there is an RFC or Internet
>Draft, or see anything on the list below that isn't right, please let me
>know. Thanks!

ATRN, draft-gellens-on-demand, SMTP relay with dynamic IP address.

Of course, this is supposed to be on its own port, so you might not
want to count it.  But someone could include the feature in a standard
SMTP server and run it on port 25 if they wanted to.

Date: Mon, 13 Apr 1998 10:42:28 -0700
From: Dan Wing <[email-masked]>
To: [email-masked]
Subject: Re: List of ESMTP extensions
Sender: [email-masked]

>> We will likely drop the proposal anyways in favor of 
>> draft-ietf-fax-mdn-features-01.txt, anyways, but if you're honestly
>> interested in a justification for draft-ietf-fax-smtp-capabilities I 
>> can give you several.
>
>Yes, I have a morbid interest in the sources of engineering disasters.

The primary reason to do this is to send color faxes and superfine
faxes, without wasting network bandwidth and without requiring the fax
offramp to downgrade color/superfine faxes if that is necessary
because it connects to a recipient fax machine that doesn't support
color/superfine.

To do this we need to know the capabilities of the recipient.  We're 
already using SMTP, so using SMTP to determine the capabilities of
the recipient seemed like a good idea and avoids the problems of 
out-of-sync caches and the like.

Adding the SMTP extension to an offramp is trivial and solves the 
problem in a way that is analogous to how today's fax machines 
determine recipient capabilities exchange.

As I said, though, we're probably going to let this I-D expire so 
going into a lengthy debate isn't useful.

-Dan Wing

Date: Mon, 13 Apr 1998 11:02:09 -0400
To: "D. J. Bernstein" <[email-masked]>, [email-masked]
From: "Jack De Winter" <[email-masked]>
Subject: Re: List of ESMTP extensions
Sender: [email-masked]

At 06:47 PM 4/10/98 -0000, D. J. Bernstein wrote:
>See http://pobox.com/~djb/surveys/smtpextensions.txt. You missed ONEX,
>VERB, and VRFY. There are also lots of X extensions that should be
>documented.
>
>> CAPABILITIES|draft-ietf-fax-smtp-capabilities|Finding out server
capabilities
>
>I continue to be amazed at this proposal. Previous commentary:
>
>: CAPS has surpassed ETRN in the ``Most absurd use of port 25'' contest.
>: 
>: Has anyone informed the authors that store-and-forward mail systems do
>: not provide an online end-to-end link from the receiver to the sender?

Well, seeing as we are supposed to be writing software so that people
can use it, and there is and was a need to support transient connections
that wanted SMTP access, I dont think 'absurd' should be applied to ETRN.

However, seeing as everytime I have tried to check one of Dan's web pages
(with the plethora of information that is supposed to be stored there) and
I get an extended error and no web pages back from the server, I really
dont put much faith in those opinions.

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 884-4498		http://www.wildbear.on.ca/jacks/

Date: 11 Apr 1998 23:02:43 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: List of ESMTP extensions
Sender: [email-masked]

Dan Wing writes:
> RFC1869 seems to indicate that VRFY is required and thus doesn't need
> to be advertised in an EHLO response.

Sorry---I assumed the question was about the real world, not the RFCs.

> We will likely drop the proposal anyways in favor of 
> draft-ietf-fax-mdn-features-01.txt, anyways, but if you're honestly
> interested in a justification for draft-ietf-fax-smtp-capabilities I 
> can give you several.

Yes, I have a morbid interest in the sources of engineering disasters.

---Dan
Smaller, faster, safer than inetd+tcpd. http://pobox.com/~djb/ucspi-tcp.html

Date: Fri, 10 Apr 1998 18:18:43 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: handling extraneous 500 level SMTP error codes
To: Jack De Winter <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> just going through a couple of bounce messages that I have
> received back from mailing lists, and came across a couple
> of instances that cause me to question my responses.

> The first is responding to a MAIL FROM with a
> 551 <[email-masked]>... <ISPs NAME> ERROR 1 - call <#> for help.

> The second is responding to a RCPT TO with a
> 554 Could not read response from aliasd.

> Now, in both cases, I could not find (in 821 or 1123) the response
> codes listed for the commands.

While I try and use documented codes in the code I write, I've never bought
into the theory that servers which issue undocumented but structurally legal
response codes are broken. RFC821 makes it quite clear that the response code
set is intended to be extensible. It also makes it clear that interpretation of
specific codes really isn't a good thing.

> Matter of fact, user not local for
> MAIL FROM does not really make sense unless they have an anti-posting
> filter or something out in place.  Seeing as this is list traffic,
> it really didnt make sense.

People implement rejections at the MAIL FROM for all sorts of reasons. While I
tend to regard such things as fairly problematic, the fact remains that doing
this sort of thing is fairly popular and people believe they are well served by
it. And I don't think clients have any business second guessing servers in this
regard. For all you know this server has had a problem with mail that had the
MAIL FROM address you are using and is perfectly justifid in blocking it. If
the server is doing the wrong thing the right outcome is to fix it, not try and
work around it.

> The second case I can almost see treating this as I do thr 550
> to 553 responses, which indicate failures with the particular address,
> but not sufficient to abort the connection (like mailbox full, etc.).

Actually this one's a bigger problem for me. This sounds like a case where
a 4xx code should have been issued (or the address accepted and alias
expansion deferred) rather than a 5xx code. But even in a case like this
I think it is better to take the code at face value and bounce the message.

> So, any input there on how these 500 level response should be
> handled?  current usage of any of these responses to these commands?

I'd handle them by bouncing the message.

				Ned

Date: Fri, 10 Apr 1998 18:43:27 -0400 (Eastern Daylight Time)
From: John C Klensin <[email-masked]>
Subject: Re: List of ESMTP extensions
To: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]

On Fri, 10 Apr 1998 17:06:19 -0400 [email-masked] 
wrote:

> On the other hand, draft-ietf-drums-smtpupd-06.txt has this to say:
> 
> 
> Server implementations MUST support VRFY and SHOULD support EXPN.
> For security reasons, implementations MAY provide local installations
>...
> is supported.  Since they were both optional in RFC 821, they MUST,
> if supported, be listed in the response to EHLO if service extensions
> are supported.

Gaak. This is simply wrong, and the editor will go find his 
sword and fall on it.  The text in section 5 of RFC 1869 
(STD 10) is authoritative and VRFY is not listed as an 
extension/option because it is required.  It will be 
corrected in the next version of the cited I-D.

The theory here was that VRFY was promoted to "required" by 
RFC 1123, which was a long time before we did the ESMTP 
work.  And, for what I hope are obvious reasons, we wanted 
a conforming 821/1123 server implementation to be able to 
conform to ESMTP simply by recognizing EHLO and returning 
what it would have returned to HELO... that meant no 
listed response for required functions.

   john

From: [email-masked]
To: [email-masked]
Date: Fri, 10 Apr 1998 17:06:19 -0400
Subject: Re: List of ESMTP extensions
Sender: [email-masked]

On the other hand, draft-ietf-drums-smtpupd-06.txt has this to say:

Server implementations MUST support VRFY and SHOULD support EXPN.
For security reasons, implementations MAY provide local installations
a way to disable either or both of these commands through
configuration options or the equivalent.  When these commands are
supported, they are not required to work across relays when relaying
is supported.  Since they were both optional in RFC 821, they MUST,
if supported, be listed in the response to EHLO if service extensions
are supported.

>On Fri, 10 Apr 1998 12:08:21 -0700 Dan Wing
><[email-masked]> wrote:
>
>> >See http://pobox.com/~djb/surveys/smtpextensions.txt. You missed ONEX,
>> >VERB, and VRFY. There are also lots of X extensions that should be
>> >documented.
>>
>> RFC1869 seems to indicate that VRFY is required and thus doesn't need
>> to be advertised in an EHLO response.
>
>That is correct.

Date: Fri, 10 Apr 1998 15:48:09 -0400 (Eastern Daylight Time)
From: John C Klensin <[email-masked]>
Subject: Re: List of ESMTP extensions
To: Dan Wing <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

On Fri, 10 Apr 1998 12:08:21 -0700 Dan Wing 
<[email-masked]> wrote:

> >See http://pobox.com/~djb/surveys/smtpextensions.txt. You missed ONEX,
> >VERB, and VRFY. There are also lots of X extensions that should be
> >documented.
> 
> RFC1869 seems to indicate that VRFY is required and thus doesn't need
> to be advertised in an EHLO response.

That is correct.

Date: Fri, 10 Apr 1998 12:08:21 -0700
From: Dan Wing <[email-masked]>
To: [email-masked]
Subject: Re: List of ESMTP extensions
Sender: [email-masked]

>See http://pobox.com/~djb/surveys/smtpextensions.txt. You missed ONEX,
>VERB, and VRFY. There are also lots of X extensions that should be
>documented.

RFC1869 seems to indicate that VRFY is required and thus doesn't need
to be advertised in an EHLO response.

>> CAPABILITIES|draft-ietf-fax-smtp-capabilities|Finding out server capabilities
>
>I continue to be amazed at this proposal. Previous commentary:
>
>: CAPS has surpassed ETRN in the ``Most absurd use of port 25'' contest.

That's an honor.  :-)

>: Has anyone informed the authors that store-and-forward mail systems do
>: not provide an online end-to-end link from the receiver to the sender?

Yep, I'm aware of that.

>: Why would anyone even imagine putting this feature into SMTP? Is there
>: something wrong with today's public-information retrieval protocols? I
>: realize that ftpd and fingerd don't have enough hooks, but why not use
>: httpd?

We will likely drop the proposal anyways in favor of 
draft-ietf-fax-mdn-features-01.txt, anyways, but if you're honestly
interested in a justification for draft-ietf-fax-smtp-capabilities I 
can give you several.

-Dan Wing

Date: 10 Apr 1998 18:47:35 -0000
From: "D. J. Bernstein" <[email-masked]>
To: [email-masked]
Subject: Re: List of ESMTP extensions
Sender: [email-masked]

See http://pobox.com/~djb/surveys/smtpextensions.txt. You missed ONEX,
VERB, and VRFY. There are also lots of X extensions that should be
documented.

> CAPABILITIES|draft-ietf-fax-smtp-capabilities|Finding out server capabilities

I continue to be amazed at this proposal. Previous commentary:

: CAPS has surpassed ETRN in the ``Most absurd use of port 25'' contest.
: 
: Has anyone informed the authors that store-and-forward mail systems do
: not provide an online end-to-end link from the receiver to the sender?
: 
: Why would anyone even imagine putting this feature into SMTP? Is there
: something wrong with today's public-information retrieval protocols? I
: realize that ftpd and fingerd don't have enough hooks, but why not use
: httpd?

---Dan
Smaller, faster, safer than inetd+tcpd. http://pobox.com/~djb/ucspi-tcp.html

Date: Fri, 10 Apr 1998 11:16:20 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: List of ESMTP extensions
Sender: [email-masked]

Greetings again. IMC is going to be putting up a list of known ESMTP
extensions, and I wanted to do a sanity check before I posted it on the Web
site. If you don't see one below for which there is an RFC or Internet
Draft, or see anything on the list below that isn't right, please let me
know. Thanks!

8BITMIME|RFC 1652|8-bit MIME messages
AUTH|draft-myers-smtp-auth|SMTP authentication
CAPABILITIES|draft-ietf-fax-smtp-capabilities|Finding out server capabilities
CHECKPOINT|RFC 1845|Restarting transmission
CHUNKING|RFC 1830|Large and binary messages
DSN|RFC 1891|Delivery status notifications
ENHANCEDSTATUSCODES|RFC 2034|Enhanced status codes
ETRN|RFC 1985|Starting remote message queue
EXPN|RFC 821|Expand address
HELP|RFC 821|Get help
PIPELINING|RFC 2197|Command pipelining
RELAY|draft-gellens-submit|Message submission
SAML|RFC 821|Send and mail
SEND|RFC 821|Send
SESSION|draft-ietf-fax-smtp-session|Immediate delivery of messages
SIZE|RFC 1870|Announce message size
SOML|RFC 821|Send or mail
STARTTLS|draft-hoffman-smtp-ssl|SMTP over TLS
TURN|RFC 821|Switch client and host

--Paul Hoffman, Director
--Internet Mail Consortium

To: "Jack De Winter" <[email-masked]>
Cc: [email-masked]
Subject: Re: handling extraneous 500 level SMTP error codes 
From: [email-masked]
Date: Fri, 10 Apr 1998 09:50:20 -0400
Sender: [email-masked]

--==_Exmh_167298264P
Content-Type: text/plain; charset=us-ascii

On Thu, 09 Apr 1998 18:28:43 EDT, you said:
> Now, in both cases, I could not find (in 821 or 1123) the response
> codes listed for the commands.  Matter of fact, user not local for
> MAIL FROM does not really make sense unless they have an anti-posting
> filter or something out in place.  Seeing as this is list traffic,
> it really didnt make sense.

Well.. I often see stuff addressed to [email-masked]' going out,
they've botched their MX entries, and it ends up being sent to
a host that is *not* in the mood to forward it.  The other common
occurrence is when there's an *expired* mail forwarding in effect...

> So, any input there on how these 500 level response should be
> handled?  current usage of any of these responses to these commands?

Appendix E of RFC821 states:

            5yz   Permanent Negative Completion reply

               The command was not accepted and the requested action did
               not occur.  The sender-SMTP is discouraged from repeating
               the exact request (in the same sequence).  Even some
               "permanent" error conditions can be corrected, so the
               human user may want to direct the sender-SMTP to
               reinitiate the command sequence by direct action at some
               point in the future (e.g., after the spelling has been
               changed, or the user has altered the account status).

Bottom line: If the reply code starts with a 5, and you dont
know what the y and z values are supposed to mean, it's appropriate
to insert a .WAV of Dr McCoy saying "Its dead, Jim"...
-- 
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech

--==_Exmh_167298264P
Content-Type: application/pgp-signature

--==_Exmh_167298264P--

Date: Thu, 09 Apr 1998 18:28:43 -0400
To: [email-masked]
From: "Jack De Winter" <[email-masked]>
Subject: handling extraneous 500 level SMTP error codes
Sender: [email-masked]

just going through a couple of bounce messages that I have
received back from mailing lists, and came across a couple
of instances that cause me to question my responses.

The first is responding to a MAIL FROM with a
551 <[email-masked]>... <ISPs NAME> ERROR 1 - call <#> for help.

The second is responding to a RCPT TO with a
554 Could not read response from aliasd.

Now, in both cases, I could not find (in 821 or 1123) the response
codes listed for the commands.  Matter of fact, user not local for
MAIL FROM does not really make sense unless they have an anti-posting
filter or something out in place.  Seeing as this is list traffic,
it really didnt make sense.

The second case I can almost see treating this as I do thr 550
to 553 responses, which indicate failures with the particular address,
but not sufficient to abort the connection (like mailbox full, etc.).

So, any input there on how these 500 level response should be
handled?  current usage of any of these responses to these commands?

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 884-4498		http://www.wildbear.on.ca/jacks/

Date: Sun, 05 Apr 1998 17:15:25 -0800 (PST)
From: Ned Freed <[email-masked]>
Subject: Re: Max RCPT TO: - option to negotiate?
To: Steve Kille <[email-masked]>
Cc: Ned Freed <[email-masked]>, Arnt Gulbrandsen <[email-masked]>, [email-masked]
Sender: [email-masked]

> > And if you don't see the advantage, well, I would suggest that you do some
> > additional timing of SMTP behavior on high latency links. Pipelining often
> > makes a significant difference.

> It will clearly make a big improvement on latency.  How much does your
> experience suggest is helps on throughput?

FIguring how throughput is affected is much more difficult. It depends very
much on an MTA's queue processing strategy and the fan-out of message
destinations. For example, an MTA that enforces a small number of connections
per destination handling traffic to a small number of destinations is likely to
win big with pipelining. On the other hand, an MTA that doesn't pay attention
to destinations and fires up lots of connections to a large number of
destinations won't benefit much. But of course one can also argue that both of
these MTA strategies have major problems with certain kinds of loads.

In practice our customers tune things to process messages based on the mix of
traffic they handle, not on the basis of making pipelining work better. In most
cases we see pipelining give some benefit; it is rare for it to have no effect
and equally rare for it to win big.

				Ned

To: Ned Freed <[email-masked]>
cc: Arnt Gulbrandsen <[email-masked]>, [email-masked]
Subject: Re: Max RCPT TO: - option to negotiate?
Date: Thu, 02 Apr 1998 20:27:29 +0100
From: Steve Kille <[email-masked]>
Sender: [email-masked]

Ned,

 >> I noted the reference to Isode's PP (we do still call it PP, but for
 >> marketing purposes it goes under the title "Internet/X.400 Message Switch".)
 >
 >I hope you won't mind if I continue to refer to it as PP. 

Of course not!!

 >Um, this demonstrates a misunderstanding of the benefits of pipelining. A
 >server that claims pipelining but _clients_ are the ones that take advantage of
 >it. As such, it is beneficial to the community for a pipeline-clean server to
 >claim pipelining even if the client in the same software package doesn't take
 >advantage of it (yet).

Point taken.   We'll get this change made and the server will claim
pipelining in the next release.

 >
 >And if you don't see the advantage, well, I would suggest that you do some
 >additional timing of SMTP behavior on high latency links. Pipelining often
 >makes a significant difference.

It will clearly make a big improvement on latency.  How much does your
experience suggest is helps on throughput?

 >Then you might want to consider enabling it on the version of PP that serves
 >isode.com. Both it and the half-dozen other PP servers I tested did not offer
 >ESMTP support.

Will do

 >
 >				Ned
 >

Steve