"Andreas M. Kirchwitz" <amk(_at_)krell(_dot_)zikzak(_dot_)de> writes:
1. By default, it deletes mail.
What surprises me most is the fact that fetchmail's default
configuration is to delete any undeliverable mail without
any notification when the transfer to the destination
SMTP server fails with certain error codes.
The manual calls it "antispam" feature, but - for example -
getting an SMTP error code 550 doesn't necessarily mean that
it's spam.
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.
It could be a syntactically incorrect header,
What should fetchmail do instead?
or a temporary DNS problem.
A temporary DNS problem ("no response") should give 4XX class replies,
not 5XX. If your SMTP listener returns 5XX on temporary problems, it's
misconfigured or broken.
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.
2. How to disable bounces?
If the "antispam" feature is disabled, a bounce is generated
for an undeliverable mail.
...
(The --nobounce option still sends bounces, but to the postmaster
who typically doesn't care much about a user's problem with his
fetchmail installation. Think of a multi-user system. ;-)
But it's the cure.
3. Delivery failure report?
Instead of bounces to the original sender, a delivery failure
report (to a defined mail address on a per user basis) would
be more helpful.
The original sender cannot do much about my fetchmail problems.
But the final receiver (the person that should have got the
mail via the SMTP server -- me! ;-) is the person that is interested
most in any problems that happened during the fetchmail process.
Currently, the final receiver has no idea that there was failed
mail delivery. A meaningful notification would be very nice, IMHO.
However, if the final delivery fails, the delivery of the bounce may
also fail for the same reason (.procmailrc hosed, for example).
[Please Cc: Andreas on followups, he's not on the list.]
--
Matthias Andree