ietf-smtp
[Top] [All Lists]

Re: mail-abuse.org tests, and weird addresses...

2000-07-18 21:06:56

--On Tuesday, July 18, 2000 2:32 PM -0400 
Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu
wrote:

(Am cc'ing the IETF-SMTP list, hopefully it's alive and
somebody there will have guidance on this... For the IETF-SMTP
list, the discussion is what to properly do if handed this
during an SMTP transaction:

MAIL FROM:<user(_at_)domain(_dot_)name@other.domain>

Sendmail currently issues a '250 OK'.
...   [more of original message  below]...

Hi.

If my memory is correct, 501 (syntax error) is intended, as was
the exclusion of 553 from the MAIL FROM responses.  I agree that
the 1123 text is a little muddy (and it is probably at least
partially my fault).  Please take a look at
draft-ietf-drums-smtpupd-12.txt and see if you think it is clear
and good enough; if not, comments should probably go to the DRUMS
list (copied on this response).

I would think that 553 would be used for a situation in which,
e.g., the left-hand-side (local-part) of an address was valid
syntax in 821 (etc) terms, but invalid for processing/ delivery
on the target host while 501 would be used for things that were
lexically unacceptable given the 821 grammar.  If that were the
theory, then a receiving SMTP wouldn't be able to comment on the
sender's local part (in MAIL FROM) as long as it obeyed the 821
syntax.  But, again, a receiving host could evaluate a local-part
syntax against its own rules.

For example, assume my host receives 

  RCPT TO:<bogus\ user(_at_)my(_dot_)domain>

Almost no one has mailbox names that look like that, so bouncing
it with a 553 would be reasonable.  Bouncing it with 501 would be
less so, since the syntax, is I believe,  821-valid.  On the
other hand, the example given below is invalid everywhere in 821
systems.

      john


On Tue, 18 Jul 2000 10:46:13 PDT, Kyle Jones
<kyle_jones(_at_)wonderworks(_dot_)com>  said:
The attitude I took when I ran a relaying server was that stuff
like a(_at_)b@c was better off bounced immediately. 

I can deal with that attitude.

However, RFC821 also lists the following codes on page 56:

         550 Requested action not taken: mailbox unavailable
            [E.g., mailbox not found, no access]
         551 User not local; please try <forward-path>
         552 Requested mail action aborted: exceeded storage
         allocation 553 Requested action not taken: mailbox
         name not allowed [E.g., mailbox syntax incorrect]
         554 Transaction failed

But then continues to say:

            MAIL
               S: 250
               F: 552, 451, 452
               E: 500, 501, 421
            RCPT
               S: 250, 251
               F: 550, 551, 552, 553, 450, 451, 452
               E: 500, 501, 503, 421

(I.e. you can toss a 553 on the RCPT TO, but not on a MAIL
FROM).

RFC1123 then muddies things up more:

      5.2.10  SMTP Replies:  RFC-821 Section 4.2

         A receiver-SMTP SHOULD send only the reply codes
         listed in section 4.2.2 of RFC-821 or in this
         document.  A receiver-SMTP SHOULD use the text shown
         in examples in RFC-821 whenever appropriate.

         A sender-SMTP MUST determine its actions only by the
         reply code, not by the text (except for 251 and 551
         replies); any text, including no text at all, must be
         acceptable.  The space (blank) following the reply
         code is considered part of the text.  Whenever
         possible, a sender-SMTP SHOULD test only the first
         digit of the reply code, as specified in Appendix E of
         RFC-821.

         DISCUSSION:
              Interoperability problems have arisen with SMTP
              systems using reply codes that are not listed
              explicitly in RFC- 821 Section 4.3 but are legal
              according to the theory of reply codes explained
              in Appendix E.


So, is it legal/permissible/suggested to 553 on a MAIL FROM
that can be determined to be syntactically invalid?
-- 
                               Valdis Kletnieks
                               Operating Systems Analyst
                               Virginia Tech