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
bivansc@rotaryintl.org
-----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: 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
bivansc@rotaryintl.org