ietf-smtp
[Top] [All Lists]

Re: SMTP 551 code in use?

2003-03-24 09:46:24
On Mon, 24 Mar 2003 15:02:26 +0100, Arnt Gulbrandsen 
<arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no>  said:
when I (acting as SMTP client) send rcpt to and receive a 551 code from 
a server, it might be a good idea to use the referenced e-mail address 
instread of the one I used. Final decision left to the user, of course.

I'm not clear what you mean by "referenced address instead of the one I used"?

RFC2821, section 4.2.2:

      551 User not local; please try <forward-path>

Pretty clear that the server is supposed to give you a forward-path that
is usable in a RCPT TO: (if the 551 reply is supported at all, some sites
may disable it due to the inherent information leakage).

So what happens is:

VRFY foo(_at_)some-domain(_dot_)com
551 User not local; please try <new-foo(_at_)some(_dot_)new-place(_dot_)net>

However, I can't find any formal grammar for the text supplied by 551. 
Is there one? Can I expect server implementations to conform to this 
well-hidden grammar (assuming there are server implementations that 
return 551 at all)?

RFC2821, section 3.5.2:

   When normal (2yz or 551) responses are returned from a VRFY or EXPN
   request, the reply normally includes the mailbox name, i.e.,
   "<local-part(_at_)domain>", where "domain" is a fully qualified domain
   name, MUST appear in the syntax.  In circumstances exceptional enough
   to justify violating the intent of this specification, free-form text
   MAY be returned.  In order to facilitate parsing by both computers
   and people, addresses SHOULD appear in pointed brackets.  When
   addresses, rather than free-form debugging information, are returned,
   EXPN and VRFY MUST return only valid domain addresses that are usable
   in SMTP RCPT commands.  Consequently, if an address implies delivery
   to a program or other system, the mailbox name used to reach that
   target MUST be given.  Paths (explicit source routes) MUST NOT be
   returned by VRFY or EXPN.

This seems to indicate that your parser should look for a regexp of the form
"<lhs(_at_)rhs>", with possibly other text before or after.


-- 
                                Valdis Kletnieks
                                Computer Systems Senior Engineer
                                Virginia Tech

Attachment: pgpo7KJffySz9.pgp
Description: PGP signature

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