Quoting from Matthias Andree's mail on Mon, Aug 26, 2002 at 11:20:42PM +0200:
What MTA yields 550 when the mail is in fact deliverable?
Indeed, "no such user" (which is a configuration error, such as a typo
in the "user hans is andreas here" part) will yield 550 in many cases,
but this should be tested for before putting a system into production.
In a multidrop case, 550 is in fact the most common reason for mail
rejection. Including it in the antispam code by default leads to
missing bounces for valid mails.
I presume, this means that 550 should be added in the single drop case
only. This means that the default antispam list should be different
for multidrop and single drop cases.
Okay, this can be disabled with "antispam -1" (what only seems
to work if used in the fetchmailrc file, but not if used on the
command line ;-) I had expected that "antispam -1" is the
default (because it's much safer this way).
I'd second that this be changed for fetchmail 6.0.0.
On trying this, I found that the for each invalid user, a double
bounce is generated! This has already been reported before and the fix
had lead to missing bounces on invalid users in the multidrop case.
Refer to:
<http://lists.ccil.org/pipermail/fetchmail-friends/2001-September/001005.html>
I now realise that the reason for the missing bounces was the
inclusion of 550 in antispam by default!
On tracing, it shows that for each invalid recipient, open_smtp_sink()
calls handle_smtp_report() which can call send_bouncemail(). Also, at
the end, if there are any invalid recipients, send_bouncemail() is
called with all invalid recipients. This leads to the double bounces.
In fact, this leads to (number of invalid recipients)+1 bounce mails,
though nobody seems to have reported this! When
EXPLICIT_BOUNCE_ON_BAD_ADDRESS is undefined, this leads to one bounce
mail less. However, when 550 is included in the spam list, this leads
to no bounce mails at all!
On analysing the report now:
<http://lists.ccil.org/pipermail/fetchmail-friends/2001-August/000864.html>
First bounce: (note 550 is not in antispam)
| General SMTP/ESMTP error.
| ---
| Reporting-MTA: dns; ludwig.ping.de
| | Final-Recipient: rfc822; testuser
| Last-Attempt-Date: Sun, 05 Aug 2001 19:41:48 +0200 (CEST)
| Action: failed
| Status: 5.0.0
| Diagnostic-Code: 550 <testuser(_at_)ludwig(_dot_)ping(_dot_)de>: User
unknown
This bounce has come from send_bouncemail() called from
handle_smtp_report().
Second bounce:
| Some addresses were rejected by the MDA fetchmail forwards to.
| -----
| Reporting-MTA: dns; ludwig.ping.de
| | Final-Recipient: rfc822; testuser
| Last-Attempt-Date: Sun, 05 Aug 2001 19:41:48 +0200 (CEST)
| Action: failed
| Status: t.0.0
| Diagnostic-Code: testuser: 221 Bye
This has come from send_bouncemail() called after all the smtp
transaction. The most weird thing is the Diagnostic-Code: which is
incorrect because it comes from the last smtp response which was
modified by send_bouncemail() called from handle_smtp_report()!
Also, the Status: is weird (t.0.0 instead of 2.0.0 in this case)
because the user id is also prepended to the (incorrectly) saved error
message.
The fix is to call a modified handle_smtp_report() which does not send
a bounce mail at all.
Here is a patch which fixes the double (or to be more accurate,
multiple) bounce. In addition, it fixes the following bugs:
1) when multiple recipients are rejected, the final send_bouncemail()
reports a spurious
Internal error: SMTP error count doesn't match number of recipients.
2) a 553 can come from an invalid "RCPT TO" too. The (unused) code
reports it as an invalid "MAIL FROM" only.
3) The user id is prepended to the saved smtp_response. Later, the
user id is parsed for the smtp code and an invalid status is reported.
Since the user id is already reported in Final-Recipient:, there is no
need to save it here separately.
4) a transient error is checked for only if there are no good
addresses. In the multidrop case, this can cause some users to not get
the mail. also, the bounce mail is sent before the mail is kept for
transient errors. this can cause a bounce mail to be sent repeatedly
till the transient error is cleared. the solution is to do the
transient error check before all the other checks. In fact, it is
possible to return immediately after the first transient error,
however I have allowed the rcpt to transaction to continue before
returning with a transient error.
I have not removed the EXPLICIT_BOUNCE_ON_BAD_ADDRESS in this patch,
however I feel that that flag should be removed if this patch is
otherwise acceptable.
Sunil Shetye.
fetchmail-5.9.13-doublebounce.patch
Description: Text document