Am 29.08.24 um 20:17 schrieb Manny:
Package: fetchmail
Version: 6.4.37-1
Severity: normal
Tags: upstream
X-Debbugs-Cc: debbug.fetchm...@sideload.33mail.com
The failure scenario played out like this:
① sent a message that was larger than the receiving server accepts
② the email provider’s SMTP server rightfully generated a bounce message and
delivered it to the inbox of the sender. But the Return-Path: lacked a domain and was
therefore RFC non-complaint. Specifically, the header was→ “Return-Path:
<MAILER-DAEMON>”
③ fetchmail fetched the bounce message then used the Return-Path header to attempt to
construct a valid envelope-from address in the local SMTP session. It sent this→
“MAIL FROM:<MAILER-DAEMON@127.0.0.1> BODY=8BITMIME SIZE=4623”. That is also RFC
non-compliant by today’s standards. IP addresses must be bracketed in order to be
valid. (I think in the 1990s a naked IP address was valid)
④ Postfix locally generates another bounce message containing this:
In: MAIL FROM:<MAILER-DAEMON@127.0.0.1> BODY=8BITMIME SIZE=4623
Out: 501 5.1.7 Bad sender address syntax
The first defect to manifest is the email provider generating a
malformed Return-Path (obviously not a fetchmail bug). The second bug
is fetchmail botching the “MAIL FROM” header in attempt to salvage the
bad Return-Path.
I take it your mail provider uses Postfix and you claim it messes up?
The postconf(5) manual page (command: man 5 postconf) states:
empty_address_recipient (default: MAILER-DAEMON)
The recipient of mail addressed to the null address. Postfix
does not accept such addresses in SMTP commands, but they may
still be created locally as the result of configuration or
software error.
So that's upstream business, they have the means to make that valid --
and not fetchmail's business to fix.
Are you using multidrop? =>
<https://www.fetchmail.info/fetchmail-FAQ.html#G3>
It’s nice that fetchmail tries to be forgiving and work with bad
input. But if it’s going to take that route then it needs to generate
valid output. A low-effort fix is to simply add brackets around the IP
address.
Agreed, but 6.4 is frozen upstream, so changes would be in 6.5 and
available for backporting through the Debian package maintainer.
A better fix is likely to extract a domain name from the “From:”
header and use that instead of the localhost IP address. But note that
it may be non-trivial considering that the “From:” field could legally
contain mutliple addresses. Or the “From:” field could also be invalid
in the same way, in which case finding a sensible domain might become
more of a crap shoot. In my particular scenario, my email provider had
a trivial and proper “From:” field as: mailer-dae...@mx.server.tld.
Not going to happen. We shall not confuse envelope and header addresses
only to delay the problem. And if the envelope sender isn't the null
sender (which you reported as MAILER-DAEMON), why would we know it's a
bounce and we want special handling?
The general requirement is that whatever upstream accepts, must be
accepted by the server that fetchmail forwards to. The assumption is
that the latter is under your control, so you can relax policies for the
localhost.
Alternative /possible/ fix:
Perhaps outsourcing this to formail is sensible? I sometimes have to
process email locally by feeding messages with missing headers into
procmail. E.g.
$ formail < msg_with_bad_or_missing_headers > proper_msg.mbox
Also not going to happen. I am not going to touch that pile of bitrot
(not even with a barge pole) that had bogus concepts 30 years ago and
hasn't been maintained for more than a quarter century and source all
the procmail bugs in. That includes resorting to empiric second-guessing
behavior of antediluvian software such as procmail/formail.
