FW: smtp transport seemingly eating bounceback failures

[Crispin Bivans <BivansC@rotaryintl.org>]

I saw one of my earlier patches (about 100% cpu in scheduler/threads.c) but
this bug below about swollowing bounceback emails still seems to be
unresolved (just checked CVS source today). Has anybody had any comments or
problems with the suggested code?
 
-Crispin
 
-----Original Message-----
From: Crispin Bivans [mailto:BivansC@rotaryintl.org] 
Sent: Tuesday, March 13, 2001 1:15 PM
To: 'zmailer@nic.funet.fi'
Subject: RE: smtp transport seemingly eating bounceback failures



In looking more into the problem described below, I uncovered that the
questionable logic I'm talking about was only a problem starting in the
latest version 2.99.55. The prior version .54 had this smtp.c logic which
works:

        if (rc == EX_OK) { 
          /* Study the DATA STATES! */ 
          if (SS->rcptstates & DATASTATE_400) 
            rc = EX_TEMPFAIL; 
          if (SS->rcptstates & DATASTATE_500) 
            rc = EX_UNAVAILABLE; 
        } 

The new faulty logic looks like: 

	if (rc == EX_OK) { 
  /* Study the DATA STATES! */ 
  if (SS->rcptstates & DATASTATE_OK) 
    rc = EX_OK; /* Some ok! */ 
  else if (SS->rcptstates & DATASTATE_400) 
    rc = EX_TEMPFAIL; /* Some TEMPFAIL */ 
  else if (SS->rcptstates & DATASTATE_500) 
    rc = EX_UNAVAILABLE; /* All hard failures */ 
} 

I'm not sure what the new code was intending to do but it has broken the
ability of smtp transport to recognize 'No such person' errors from email
servers that issue such errors after a DATA section. Yahoo.com in particular
does this plus I'm sure many more. Any bad emails to those domains is
silently dropping the message without reporting back a bounceback.

Prior releases of Zmailer, plain old sendmail and Exchange all handle
situation correctly. 

For now I'm going to put back the old logic (from prior releases) but please
somebody let us know what the new logic was for and how it could be cured.

-Crispin Bivans 
 <mailto:bivansc@rotaryintl.org> bivansc@rotaryintl.org 

	BM__MailData-----Original Message----- 
From:   Crispin Bivans 
Sent:   Monday, March 12, 2001 4:46 PM 
To:     'zmailer@nic.funet.fi' 
Subject:        smtp transport seemingly eating bounceback failures 

	I installed the latest Zmailer with what I think of as a pretty
simply config. Its intended for supplementing a busy exchange server for
large bulk emails to company mailing lists. Zmailer itself would never
receive any emails (and wasn't listed as an MX for the domain) just being
mostly outbound only.

	While doing tests, I determined that it appears that the 'smtp'
transport is reporting Status of 'OK' (listed in maillog as 'ok3')  even
when a badly named email is sent to yahoo. (Example:
<mailto:asdljasdhsah@yahoo.com)> asdljasdhsah@yahoo.com). No bounceback
message came back to the sending user (I tried many... root, normal users,
etc..), never informing them of the failure to reach a valid user. I know it
should have, because a logging of the SMTP session shows that it returned a
554 Error 'This user doesn't have a yahoo.com account' after reading the
Email DATA.

	I turned on debugging and even added my own extra logging lines to
smtp.c to catch what it was doing with the rcptstates and rc value. I
finally determined it had some apparently faulty (?) logic that if it had
earlier gotten a DATASTATE_OK (this session apparently did) and also a
DATASTATE_500 then it would set the return code to 0 (OK). I changed the
logic and I think I'm getting the behavior I want (although the return code
is slightly different then it would have for an invalid user). I'm hoping
the programmers of zmailer have an idea of what happened and how it should
have behaved.

	I modified the following logic in smtp.c: 

	From: 
        if (rc == EX_OK) { 
          /* Study the DATA STATES! */ 
          if (SS->rcptstates & DATASTATE_OK) 
            rc = EX_OK; /* Some ok! */ 
          else if (SS->rcptstates & DATASTATE_400) 
            rc = EX_TEMPFAIL; /* Some TEMPFAIL */ 
          else if (SS->rcptstates & DATASTATE_500) 
            rc = EX_UNAVAILABLE; /* All hard failures */ 
        } 
To: 
        if (rc == EX_OK) { 
          /* Study the DATA STATES! */ 
          if (SS->rcptstates & DATASTATE_OK) 
            rc = EX_OK; /* Some ok! */ 
          /* else */ 
               if (SS->rcptstates & DATASTATE_400) 
            rc = EX_TEMPFAIL; /* Some TEMPFAIL */ 
          else if (SS->rcptstates & DATASTATE_500) 
            rc = EX_UNAVAILABLE; /* All hard failures */ 
        } 

	Is what I did 'correct'? I'm hoping there is a better 'standard' way
to handle this situation... Perhaps DATASTATE_OK never should have been
triggered?

	-Crispin Bivans 
 <mailto:bivansc@rotaryintl.org> bivansc@rotaryintl.org