Re: smtp.c ignoring 451?

[Matti Aarnio <mea@nic.funet.fi>]

On Wed, Jun 29, 2005 at 04:48:17PM -0400, Peter Ip wrote:
> Hi,
> 
> We're running 2.99.55. We've discovered entries in our mail log like:
> 
> Jun 29 03:32:56 mymachine smtp[3465]: S1355559AbVF2HcX: 
> to=<361khcdz@yahoo.co.kr>, delay=00:00:33, xdelay=00:00:23, mailer=smtp, 
> relay=mx3b.mail.yahoo.co.kr ([202.165.108.248|25|128.100.132.44|60522]), 
> stat=ok3 ^M->> 451 mta104.mail.krs.yahoo.com Resources temporarily 
> unavailable. Please try again later [#4.16.5]. cvt=NONE
> 
> The 'stat=ok3' suggests that smtp.c thinks the message was successfully 
> delivered. But the other end clearly sent a '451'. The user says they 
> never got the message at the other end, e.g. yahoo.com.
> 
> There are many other log records where the '451' results in stat=deferred
> or stat=retryat which then results in subsequent attempts. So not all 
> 451's result in dropped messages.

  This sounds familiar.

  I recall having seen something like this, when there was PIPELINING
  capability declared by the remote system.

  I can't find anything referring to it in the ChangeLog, but it doesn't
  happen anymore, either.  (Checking vger.kernel.org logs.)

  ... 20 seconds latter ...

  2002-04-05  Matti Aarnio  <mea@zmailer.org>

       * transports/smtp/smtp.h, transports/smtp/smtp.c:
           Debugging oddball 'yield OK when DEFER is correct' problems..
           .. and fixed the blunder in the call of  smtpopen().


  That must be it.

> Help!
> 
> Peter
> 
> _____________________________________________________
> Peter Ip, PhD
> Computing and Network Services, University of Toronto
> email: peter.ip@utoronto.ca
-- 
/Matti Aarnio	<mea@nic.funet.fi>
-
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to majordomo@nic.funet.fi