hoh@??? writes:
>
> 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:
>
> $ telnet mx13.nameplanet.com 25 =20
> 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=3DLOGIN
> 250-PIPELINING
> 250 8BITMIME
> MAIL FROM:<>
> 250 ok
> RCPT TO:<user@???>
>
> 553 listed as badmail
> Connection closed by foreign host.
> $=20
>
> RFC 821 says that 553 is "Requested action not taken: mailbox name not allowed"
> 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?
>
> 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?
You are missing the point: Exim never got to see the 553 because it is
preceded by a blank line. This is a protocol error, and protocol errors
are normally taken to be a reason to defer, rather than to fail.
It does seem that Exim could have been clearer in its log that the protocol
error was in response to a RCPT, even though (because of pipelineing) it
had got as far as sending DATA.
Chris Thompson
Email: cet1@???
