[pkg-fetchmail-maint] Bug#349726: fetchmail: MAIL FROM: derived from Return-Path may cause double-bounces and bounceloops

[Andreas Beck]

Package: fetchmail
Version: 6.2.5-12sarge4 - should apply to any
Severity: wishlist


When fetchmail is delivering via SMTP, it peruses the content of the 
Return-Path header from the downloaded message as MAIL FROM: argument.

However, when downloading via POP, the return path of bounces is usually
set to the mailer daemon that sent the bounce, as the mailserver that
delivers to the POP-box sets it, as it does (from its point of view) 
a final delivery.

This results in bounce messages not being marked as such to the
mailserver that does the "real" final delivery.

If now - due to some misconfiguration or similar - the message will be
undeliverable, it will generate a bounce, as it cannot detect, that it
is already acting on a bounce message and shouldn't send a bounce-bounce.

Moreover, one cannot use constructs like exim's "if error_message ...",
to e.g. do authbounce-detection, as they will not match these bounces.


The feature I request would that be to introduce an option
"envelopefrom" or similar, that works on the MAIL FROM: line just like 
the "envelope" option does for the RCPT TO:.

The option should default to "Return-path", thus keeping backward
compatibility.

In my case, and probably many others, setting the option to 
"X-Envelope-From" should do the trick, as the servers filling my 
mailboxes add "X-Envelope-From" and "X-Envelope-To" to the messages,
with X-Envelope-From correctly stating "X-Envelope-From: <>".

I am aware, that one might argue about POP not being a way to _transport_
mail after all, and one should rather switch to ETRN, ODMR, uucp or 
similar, but pop-accounts are widely used for this kind of thing,
because you can get at them cheap and without seeking long for a
provider that will support anything else.

I am also aware, that it is probably easily possible to use exims
rewriting capabilities to fake up the envelope-from from the 
X-Envelope-From:-Header. However, this would be an exim-specific 
ugly hack.


Kind regards, 

Andy

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (800, 'testing'), (600, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15
Locale: LANG=C, LC_CTYPE=de_DE.ISO-8859-1 (charmap=ISO-8859-1)