The RFC states that it 'should':

"typically with a string such as "no such user - " and the mailbox name.

Right now, it just returns back 'unknown' without an associated user name for tracking down this problem.  That is what I was referring to. 

Netscape will return back the exact server message, in this case 'unknown user'.  This might be extremly assistive when tracking down incorrect users, since the address that is invalid will be returned to the client. 

J

Doug Nelson wrote:
[log in to unmask]">
I don't follow this.  What do you think that mail.msu.edu is doing
incorrectly?  From what I see, it is returning 250 for each RCPT
with a valid id, and 5xx for each invalid recipient line.  That is
exactly what my reading of the RFC would indicate should happen.
Given what mail.msu.edu returns, , it should be easy for the sender
to match up the failed recipients with the matching 5xx code.
It's unfortunate that some of the clients seem not to reasonably
follow the spec.

Doug


  
technically, RFC 2821 states:

 The first or only argument to this command includes a forward-path
   (normally a mailbox and domain, always surrounded by "<" and ">"
   brackets) identifying one recipient.  If accepted, the SMTP server
   returns a 250 OK reply and stores the forward-path.  If the recipient
   is known not to be a deliverable address, the SMTP server returns a
   550 reply, typically with a string such as "no such user - " and the
   mailbox name (other circumstances and reply codes are possible).
   This step of the procedure can be repeated any number of times.

However, in practice, some servers do not perform recipient
   verification until after the message text is received.  These servers
   SHOULD treat a failure for one or more recipients as a "subsequent
   failure" and return a mail message as discussed in section 6.  Using
   a "550 mailbox not found" (or equivalent) reply code after the data
   are accepted makes it difficult or impossible for the client to
   determine which recipients failed.

(http://ftp.rfc-editor.org/in-notes/rfc2821.txt)

mail.msu.edu is not doing this.  if the client is using pipelineing, it
should accept as long as one RCPT TO address was valid.

the simplest fix would be:

(http://www.exim.org/exim-html-4.30/doc/html/FAQ_4.html)

Q0416:
<http://www.exim.org/exim-html-4.30/doc/html/FAQ.html#TOC155>  What is
quickest way to set up Exim so any message sent to a non-existing user
would bounce back with a different message, based on the name of
non-existing user?

A0416:  Place this router last, so that it catches any local addresses
that are not otherwise handled:

   non_exist:
     driver = accept
     transport = non_exist_reply
     no_verify

Then add the following transport to the transports section:

   non_exist_reply:
     driver = autoreply
     user = exim
     to = $sender_address
     subject = User does not exist
     text = You sent mail to $local_part. That's not a valid user here. \


            The subject was: $subject.


jason

Ed Symanzik wrote:

    
/home/zik> telnet mail.msu.edu smtp
Trying 35.9.75.123...
Connected to mail.msu.edu.
Escape character is '^]'.
220 sys23.mail.msu.edu ESMTP Exim 4.24 Wed, 24 Mar 2004 14:12:34 -0500
ehlo foo
250-sys23.mail.msu.edu Hello hardy.cl.msu.edu [35.8.3.246]
250-SIZE 52428800
250-PIPELINING
250-AUTH PLAIN LOGIN
250-STARTTLS
250 HELP
mail from: [log in to unmask]
250 OK
rcpt to: [log in to unmask]
550 unknown user
rcpt to: [log in to unmask]
550 unknown user
rcpt to: [log in to unmask]">[log in to unmask],[log in to unmask]
501 [log in to unmask]:">[log in to unmask],[log in to unmask]: malformed address: ,[log in to unmask] may not
follow [log in to unmask]
rcpt to: [log in to unmask]
250 Accepted
data
354 Enter message, ending with "." on a line by itself
Subject: foo

test
.
250 OK id=1B6DrC-0004kF-96
quit
221 sys23.mail.msu.edu closing connection
Connection closed by foreign host.



This test came through ok, even though there were previous lines with
unknown users.  I did a similar test with Mozilla and it refuses to
send the message.  Looks to me like a client feature.  Not terribly
friendly though that it won't tell you which address failed.

Note, this is one method of finding which address is bad.

I believe the difference in behavior here is that Pilot would accept
mail for accounts that had not yet been activated.

--
Ed Symanzik
MSU Mail Team
[log in to unmask]

      
    



Doug Nelson, Network Manager             |  [log in to unmask]
Academic Computing and Network Services  |  Ph: (517) 353-2980
Michigan State University                |  http://www.msu.edu/~nelson/