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. 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. 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. 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 I just did a couple tests with formail. The first msg was the same msg that fetchmail botched. When that same msg is fed to formail, formail generates a “From ” header at the top of the msg. Note the space after the From. That is apparently another way to embed the envelope-from. Formail ignored the malformed Return-Path header and used the From: header to generate the “From ” header. In another test, the Return-Path header on the input was made proper by adding an “@domain.tld”. In that case formail favored the Return-Path header over the From: header. Fetchmail could either duplicate that logic, or perhaps better outsource the job to formail to make use of code reuse benefits. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fetchmail depends on: ii adduser 3.134 ii debianutils 5.7-0.5~deb12u1 ii init-system-helpers 1.65.2 ii libc6 2.36-9+deb12u7 ii libcom-err2 1.47.0-2 ii libgssapi-krb5-2 1.20.1-2+deb12u1 ii libkrb5-3 1.20.1-2+deb12u1 ii libssl3 3.0.11-1~deb12u2 ii lsb-base 11.6 ii sysvinit-utils [lsb-base] 3.06-4 Versions of packages fetchmail recommends: ii ca-certificates 20230311 Versions of packages fetchmail suggests: pn fetchmailconf <none> ii postfix [mail-transport-agent] 3.7.10-0+deb12u1 ii systemd-resolved [resolvconf] 252.22-1~deb12u1 -- no debconf information
