Re: [Exim] Re: Malformed SMTP response

Pàgina inicial
Delete this message
Reply to this message
Autor: Matthew Byng-Maddick
Data:  
A: exim-users
Assumpte: Re: [Exim] Re: Malformed SMTP response
On Wed, Dec 05, 2001 at 04:06:15PM +0100, hoh@??? wrote:
> On 5 Dec, Suresh Ramasubramanian wrote:
> > Looks like we have the rare case of an MTA which advertises pipelining
> > and doesn't implement it properly, or maybe it took exception to the
> > contents of your bounce message for some reason?
> Obviously Exims error reporting was fooled by the pipelining. When
> trying the delivery manually using telnet (without pipelining) I
> get this:


Right

> $ telnet mx13.nameplanet.com 25                              
> Trying 62.70.3.43...
> Connected to mx13.nameplanet.com.
> Escape character is '^]'.
> 220 mx13.nameplanet.com ESMTP
> EHLO mail.mitt-eget.com
> 250-mx13.nameplanet.com
> 250-AUTH=LOGIN
> 250-PIPELINING
> 250 8BITMIME
> MAIL FROM:<>
> 250 ok
> RCPT TO:<user@???>


Everything is fine up until here.

>


This blank line that you've quoted (and I assume it isn't a mistake) is
the problem. Exim can only take the last response and act on that, because
something matching \s isn't a valid response to an SMTP command, only
\d{3}[ -] is.

> 553 listed as badmail
> Connection closed by foreign host.
> $ 
> RFC 821 says that 553 is "Requested action not taken: mailbox name not
>                           allowed"


Yes. Note the "Requested action not taken".

> but what do nameplanet.com mean when they say "listed as badmail"? Do they
> object to me sending to that user, or do they dislike the user?


Up to them. The error messages are for human consumption only, the MTA
should only act on the error code given.

> Back to Exim. Exim did not notice the 553 wich should have stopped it from
> trying furter deliveries. Instead it saw the 250 and continues the fruitless
> delivery attempts. Isn't this a serious bug in Exim?


No, it's a serious bug in the remote end, see my other explanation of
this, and the idea that you should still hit the remote admin over the
head with a large paper copy of RFC2821 and RFC2822.

MBM

-- 
Matthew Byng-Maddick         <mbm@???>           http://colondot.net/