Subject: Re: SMTP session initiation and 554

From: David Lindes <[email-masked]>
Date: Fri, 19 Feb 1999 15:06:41 -0800

Hi John (Klensin) et al,

I've had reason to look at 5xx session initiation responses lately,
and I'm thinking that the text in 821bis (section 3.1) would do well
to be updated.

I'm not certain what the "correct" way to change it is, but let me
first make an attempt to explain why I feel it's incomplete, and then
throw out a suggestion for a possible replacement.

I believe it should be distinguishable, at least by humans, if not
by client-MTAs, whether a host never accepts mail or whether it has
decided not to accept mail from a particular host.  (i.e. a client
should be able to tell whether they're talking to some device that
only has a server-MTA so you don't have to time out or whether they're
talking to somebody that believes them to be a spammer or other
un-allowed party)

Some of this information can certainly be sent in the descriptive text,
but I think it would make sense to actually use a different set of 5xx
error codes for these different situations.

RFC 1846 suggests using a 521 code for the case where a host never accepts
mail from anyone.  821bis (version 9) suggests using 554, and doesn't
define when you might want to use that (though, as I read it, it does make
some vague suggestion of similar motivations to RFC 1846, when it suggests
that the client-MTA is "probably in error").

I think that the distinction would be best drawn on lines of "this host
doesn't process mail" (i.e. a router or a network appliance of some sort)
vs. "administratively prohibited" (which could be a spam thing, or that
you're connecting from the Internet to a machine that is meant only to
talk to the LAN at a certain site, or whatever...)

I propose that the 521 code be used for the former case, and 554 be used
for the latter.  (Though I am certainly not the most knowledgeable person
in the area of when the various secondary and tertiary codes should
or should not be used, so I'm open to either of those being changed.
In fact, perhaps the "administratively prohibited" type scenario
should be generally adopted as either the x3z or x4z code set??)

So, I've said I would suggest alternate text, so I will.  I am probably
not the best author, so I won't be offended if someone re-writes this
completely, but I hope that the information in this new version can
at least be incorporated (modulo any changes to the set of 5xx codes, as
discussed in the above paragraph)...

Here's my suggestion:

The SMTP protocol allows a server to formally reject a
transaction while still allowing the initial connection as
follows: a 5XX response MAY be given in the initial connection
opening message instead of the 220.  A server taking this
approach MUST still wait for the client to send a QUIT (see
section 4.1.1.10) before closing the connection and SHOULD
respond to any intervening commands with "503 bad sequence of
commands".  If a server chooses to take this approach, it
SHOULD send either a 521 response, which SHOULD be indicative
of a host which never accepts mail (such as a non-mail-related
network appliance that simply wishes to indicate explicitly
that it does not process mail, instead of the implicit
statement made by not listening to the SMTP port), or a 554
response, which SHOULD indicate that the sender-SMTP is
administratively prohibited from sending mail to this
particular host (which might indicate that the sender is not
connecting from a network which the server is allowed to talk
to, either explicitly (e.g. a SPAM site) or implicitly (e.g. a
host outside the server's LAN)).  A server returning any 5XX
response on connection opening SHOULD provide enough
information in the reply text for the sending system to
determine what action should be taken to correct this problem
(e.g.  "No mail here, please send to mx.domain.com" or "No
permission to talk, please contact [email-masked]").

Cheers,

	David

-- 
David Lindes, KF6HFQ			Netscape Communications, Inc.
[email-masked]			http://www.netscape.com/

---

From: [email-masked] (Kai Henningsen)
Date: 20 Feb 1999 14:26:00 +0200

> talking to somebody that believes them to be a spammer or other

If you get a 5xx, you don't have to time out, period. You have to bounce.

5xx is a *permanent* error code. Retries won't help you, or at least  
that's what it claims, so you MUST NOT do retries.

As for humans, well, there's a nice text message for them that can contain  
whatever you want to tell them.

> talk to the LAN at a certain site, or whatever...)

Why is this useful? All you *really* need is "sending mail to me is  
wrong". *Any* 5xx code does that.

MfG Kai

---

From: Brad Knowles <[email-masked]>
Date: Sun, 21 Feb 1999 08:34:15 +0100

>wrong". *Any* 5xx code does that.

    True enough, but that doesn't give you the ability to make the status
reported "sticky" (i.e., applicable to more than one message bound for a
particular host).  A 554 code could be applicable to just that one
message (e.g., "We don't like that envelope sender") while a 521 code
could be applicable to *all* mail from that relay to that host (i.e., "I
don't accept mail now, and I never will.").

    Of course, the degree to which that code should be allowed to remain
sticky should probably be configurable -- I would suggest recommending a
default of being equated to the same period for which mail would normally
be held (if temporarily undeliverable) until being bounced due to
excessive age.  Of course, you could choose to cache that return status
for a shorter period of time, perhaps just the length of time for this
particular queue run.

-- 
  These are my opinions -- not to be taken as official Skynet policy
 ____________________________________________________________________
|o| Brad Knowles, <[email-masked]>            Belgacom Skynet NV/SA |o|
|o| Systems Architect, News/mail/FTP Admin   Rue Col. Bourg, 124   |o|
|o| Phone/Fax: +32-2-706.11.11/12.49         B-1140 Brussels       |o|
|o| http://www.skynet.be                     Belgium               |o|
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
                The Sky is no longer the limit

---

From: [email-masked] (Kai Henningsen)
Date: 01 Mar 1999 19:17:00 +0200

[email-masked] (Brad Knowles)  wrote on 21.02.99 in <[email-masked]>:

> particular host).

If it's received at session initiation, it quite obviously *cannot* be  
message specific, since the SMTP server hasn't *seen* any message yet.

MfG Kai