postfix malformed address with confirm replies
I’m getting bounces back from postfix (553 5.1.3 Error: malformed address) for my confirm replies.
I found a similar issue in this lists’ archives back in 2017 but that issue was supposedly fixed in version 3.2
I’m running the current docker containers.
I’m pretty sure I have all of the mailman settings in postix: " # Support the default VERP delimiter. recipient_delimiter = + unknown_local_recipient_reject_code = 550 owner_request_special = no
transport_maps = regexp:/opt/mailman/core/var/data/postfix_lmtp local_recipient_maps = regexp:/opt/mailman/core/var/data/postfix_lmtp relay_domains = regexp:/opt/mailman/core/var/data/postfix_domains "
the entries in /opt/mailman/core/var/data/postfix_lmtp look like they should match
/^matsmats-mm3-test1@mm3\.aca-aws\.s\.uw\.edu$/ lmtp:[172.19.199.2]:8024 /^matsmats-mm3-test1-bounces(\+.*)?@mm3\.aca-aws\.s\.uw\.edu$/ lmtp:[172.19.199.2]:8024 /^matsmats-mm3-test1-confirm(\+.*)?@mm3\.aca-aws\.s\.uw\.edu$/ lmtp:[172.19.199.2]:8024 /^matsmats-mm3-test1-join@mm3\.aca-aws\.s\.uw\.edu$/ lmtp:[172.19.199.2]:8024 /^matsmats-mm3-test1-leave@mm3\.aca-aws\.s\.uw\.edu$/ lmtp:[172.19.199.2]:8024 /^matsmats-mm3-test1-owner@mm3\.aca-aws\.s\.uw\.edu$/ lmtp:[172.19.199.2]:8024 /^matsmats-mm3-test1-request@mm3\.aca-aws\.s\.uw\.edu$/ lmtp:[172.19.199.2]:8024 /^matsmats-mm3-test1-subscribe@mm3\.aca-aws\.s\.uw\.edu$/ lmtp:[172.19.199.2]:8024 /^matsmats-mm3-test1-unsubscribe@mm3\.aca-aws\.s\.uw\.edu$/ lmtp:[172.19.199.2]:8024
thanks, steve
On Feb 26, 2021, at 14:08:54 PST, Mail Delivery System <MAILER-DAEMON@ip-172-31-18-222.us-west-2.compute.internal> wrote:
This is the mail system at host ip-172-31-18-222.us-west-2.compute.internal.
I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can delete your own text from the attached returned message.
The mail system<matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856@mm3.aca-aws.s.uw.edu>: host 172.19.199.2[172.19.199.2] said: 553 5.1.3 Error: malformed address (in reply to RCPT TO command) Reporting-MTA: dns; ip-172-31-18-222.us-west-2.compute.internal X-Postfix-Queue-ID: E144B8BC3C5 X-Postfix-Sender: rfc822; stephen.s.w.matsmats@gmail.com Arrival-Date: Fri, 26 Feb 2021 14:08:54 -0800 (PST)
Final-Recipient: rfc822; matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856@mm3.aca-aws.s.uw.edu Original-Recipient: rfc822;matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856@mm3.aca-aws.s.uw.edu Action: failed Status: 5.1.3 Remote-MTA: dns; 172.19.199.2 Diagnostic-Code: smtp; 553 5.1.3 Error: malformed address
From: Steve Mats Mats <willey@selby.com> Subject: Re: Your confirmation is needed to join the matsmats-mm3-test1@mm3.aca-aws.s.uw.edu mailing list. Date: February 26, 2021 at 2:08:52 PM PST To: matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856@mm3.aca-aws.s.uw.edu
On Feb 26, 2021, at 11:41:54 PST, matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856@mm3.aca-aws.s.uw.edu wrote:
Email Address Registration Confirmation
Hello, this is the GNU Mailman server at mm3.aca-aws.s.uw.edu.
We have received a registration request for the email address
willey@teamd.org
Before you can start using GNU Mailman at this site, you must first confirm that this is your email address. You can do this by replying to this message.
Or you should include the following line -- and only the following line -- in a message to matsmats-mm3-test1-request@mm3.aca-aws.s.uw.edu:
confirm d6f77a2572ef55a8b2c4ca0d77de8493fbb55856
Note that simply sending a `reply' to this message should work from most mail readers.
If you do not wish to register this email address, simply disregard this message. If you think you are being maliciously subscribed to the list, or have any other questions, you may contact
matsmats-mm3-test1-owner@mm3.aca-aws.s.uw.edu
On 2/26/21 3:34 PM, Stephen Willey Mats Mats wrote:
I’m getting bounces back from postfix (553 5.1.3 Error: malformed address) for my confirm replies.
...
I’m pretty sure I have all of the mailman settings in postix: " # Support the default VERP delimiter. recipient_delimiter = +
Yes, this is the relevant one and is correct.
...
The mail system<matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856@mm3.aca-aws.s.uw.edu>: host 172.19.199.2[172.19.199.2] said: 553 5.1.3 Error: malformed address (in reply to RCPT TO command) Reporting-MTA: dns; ip-172-31-18-222.us-west-2.compute.internal X-Postfix-Queue-ID: E144B8BC3C5 X-Postfix-Sender: rfc822; stephen.s.w.matsmats@gmail.com Arrival-Date: Fri, 26 Feb 2021 14:08:54 -0800 (PST)
Final-Recipient: rfc822; matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856@mm3.aca-aws.s.uw.edu Original-Recipient: rfc822;matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856@mm3.aca-aws.s.uw.edu Action: failed Status: 5.1.3 Remote-MTA: dns; 172.19.199.2 Diagnostic-Code: smtp; 553 5.1.3 Error: malformed address
I have no idea why Postfix is saying
matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856@mm3.aca-aws.s.uw.edu
is a malformed address, but this is a Postfix issue, not Mailman.
Can you successfully post to matsmats-mm3-test1 @mm3.aca-aws.s.uw.edu how about a help command to
matsmats-mm3-test1-request@mm3.aca-aws.s.uw.edu
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Feb 26, 2021, at 16:08:35 PST, Mark Sapiro <mark@msapiro.net> wrote:
The mail system<matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856@mm3.aca-aws.s.uw.edu>: host 172.19.199.2[172.19.199.2] said: 553 5.1.3 Error: malformed address (in reply to RCPT TO command) Reporting-MTA: dns; ip-172-31-18-222.us-west-2.compute.internal X-Postfix-Queue-ID: E144B8BC3C5 X-Postfix-Sender: rfc822; stephen.s.w.matsmats@gmail.com Arrival-Date: Fri, 26 Feb 2021 14:08:54 -0800 (PST)
Final-Recipient: rfc822; matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856@mm3.aca-aws.s.uw.edu Original-Recipient: rfc822;matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856@mm3.aca-aws.s.uw.edu Action: failed Status: 5.1.3 Remote-MTA: dns; 172.19.199.2 Diagnostic-Code: smtp; 553 5.1.3 Error: malformed address
I have no idea why Postfix is saying
matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856@mm3.aca-aws.s.uw.eduis a malformed address, but this is a Postfix issue, not Mailman.Can you successfully post to
matsmats-mm3-test1 @mm3.aca-aws.s.uw.eduhow about ahelpcommand tomatsmats-mm3-test1-request@mm3.aca-aws.s.uw.edu
Yep, all day long. A ‘help’ command succeeded. As did sending the confirm command to the -request address.
oh, and looking further at the postfix logs the message was accepted by postfix but the error pops-up when postfix tries to pass it on.
Feb 26 14:08:54 ip-172-31-18-222 postfix/smtpd[5933]: connect from mail-pj1-f50.google.com[209.85.216.50] Feb 26 14:08:54 ip-172-31-18-222 postfix/smtpd[5933]: E144B8BC3C5: client=mail-pj1-f50.google.com[209.85.216.50] Feb 26 14:08:54 ip-172-31-18-222 postfix/cleanup[5966]: E144B8BC3C5: message-id=<9B650420-A50D-4E25-8B5B-C696C388B7DA@selby.com> Feb 26 14:08:54 ip-172-31-18-222 postfix/qmgr[3214]: E144B8BC3C5: from=<stephen.s.w.matsmats@gmail.com>, size=4575, nrcpt=1 (queue active) Feb 26 14:08:54 ip-172-31-18-222 postfix/smtpd[5933]: disconnect from mail-pj1-f50.google.com[209.85.216.50] Feb 26 14:08:54 ip-172-31-18-222 postfix/lmtp[5967]: E144B8BC3C5: to=<matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856@mm3.aca-aws.s.uw.edu>, relay=172.19.199.2[172.19.199.2]:8024, delay=0.08, delays=0.05/0.01/0/0.01, dsn=5.1.3, status=bounced (host 172.19.199.2[172.19.199.2] said: 553 5.1.3 Error: malformed address (in reply to RCPT TO command)) Feb 26 14:08:54 ip-172-31-18-222 postfix/cleanup[5966]: F0C468BC3C6: message-id=<20210226220854.F0C468BC3C6@ip-172-31-18-222.us-west-2.compute.internal> Feb 26 14:08:54 ip-172-31-18-222 postfix/qmgr[3214]: F0C468BC3C6: from=<>, size=6993, nrcpt=1 (queue active) Feb 26 14:08:54 ip-172-31-18-222 postfix/bounce[5968]: E144B8BC3C5: sender non-delivery notification: F0C468BC3C6 Feb 26 14:08:54 ip-172-31-18-222 postfix/qmgr[3214]: E144B8BC3C5: removed
The mailman smtp.log show that the message came in but not much else. the mailman.log (and bounce.log) don’t show anything for that time.
Feb 26 22:08:54 2021 (27) Available AUTH mechanisms: LOGIN(builtin) PLAIN(builtin) Feb 26 22:08:54 2021 (27) Peer: ('172.19.199.1', 51934) Feb 26 22:08:54 2021 (27) ('172.19.199.1', 51934) handling connection Feb 26 22:08:54 2021 (27) ('172.19.199.1', 51934) >> b'LHLO ip-172-31-18-222.us-west-2.compute.internal' Feb 26 22:08:54 2021 (27) ('172.19.199.1', 51934) >> b'MAIL FROM:<stephen.s.w.matsmats@gmail.com> SIZE=4575' Feb 26 22:08:54 2021 (27) ('172.19.199.1', 51934) sender: stephen.s.w.matsmats@gmail.com Feb 26 22:08:54 2021 (27) ('172.19.199.1', 51934) >> b'RCPT TO:<matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856@mm3.aca-aws.s.uw.edu>' Feb 26 22:08:54 2021 (27) ('172.19.199.1', 51934) >> b'RSET' Feb 26 22:08:54 2021 (27) ('172.19.199.1', 51934) >> b'QUIT' Feb 26 22:08:54 2021 (27) ('172.19.199.1', 51934) connection lost Feb 26 22:08:54 2021 (27) ('172.19.199.1', 51934) Connection lost during _handle_client()
I’ve also reproduced this another address that is on an exchange server which is maybe a more vanilla example.
steve
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
Hi Stephen,
Mark says that
matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856@mm3.aca-aws.s.uw.edu
is legal, and I think that most servers will accept it, but RFC 5321 sets a limit of 64 octets on mailboxes[1], and your confirmation mailbox is 67 octets. (There are also limits on domain length and total address length.) Note that although the '+' has a special meaning to the final recipient, and it will be delivered to the mailbox "matsmats-mm3-test1-confirm", which is only 26 octets, intermediate MTAs don't know anything about this convention, they just see the 67-octet mailbox.
I suspect that in a modern server it should be possible to configure a larger value. What is the host with IP 172.19.199.2, do you know? Is it under your control?
Footnotes: [1] https://tools.ietf.org/html/rfc5321 4.5.3.1. Size Limits and Minimums There are several objects that have required minimum/maximum sizes. Every implementation MUST be able to receive objects of at least these sizes. Objects larger than these sizes SHOULD be avoided when possible. However, some Internet mail constructs such as encoded X.400 addresses (RFC 2156 [35]) will often require larger objects. Clients MAY attempt to transmit these, but MUST be prepared for a server to reject them if they cannot be handled by it. 4.5.3.1.1. Local-part The maximum total length of a user name or other local-part is 64 octets.
On 2/27/21 4:36 AM, Stephen J. Turnbull wrote:
Hi Stephen,
Mark says that
matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856@mm3.aca-aws.s.uw.edu
is legal, and I think that most servers will accept it, but RFC 5321 sets a limit of 64 octets on mailboxes[1], and your confirmation mailbox is 67 octets.
Since the -confirm+<token> part is fixed at 49 octets, this would imply a limit in list names of 15 octets. Ouch!
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
On 2/27/21 4:36 AM, Stephen J. Turnbull wrote:
is legal, and I think that most servers will accept it, but RFC 5321 sets a limit of 64 octets on mailboxes[1], and your confirmation mailbox is 67 octets.
Since the -confirm+<token> part is fixed at 49 octets, this would imply a limit in list names of 15 octets. Ouch!
I'm pretty sure we would have run into this before, if there were a lot of servers out there imposing this limit. 15 octets is pretty darn short, there are probably quite a few list names out there longer than that. Not to mention that the RFC itself says "you SHOULD NOT be a jerk about this". :-) So I don't think this is a big problem in practice, and I hope Steve can reconfigure the obstructive server to not be so picky.
For Mailman, I doubt we need a full SHA1 (?) for the purpose. We can truncate the thing, probably opportunistically (ie, so the whole confirmation mailbox fits in 64 octets, or we could even parse the bounce message and resend only if we run into a problem).
Steve
On Feb 28, 2021, at 01:32, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Mark Sapiro writes:
On 2/27/21 4:36 AM, Stephen J. Turnbull wrote:
is legal, and I think that most servers will accept it, but RFC 5321 sets a limit of 64 octets on mailboxes[1], and your confirmation mailbox is 67 octets.
Since the -confirm+<token> part is fixed at 49 octets, this would imply a limit in list names of 15 octets. Ouch!
I'm pretty sure we would have run into this before, if there were a lot of servers out there imposing this limit. 15 octets is pretty darn short, there are probably quite a few list names out there longer than that. Not to mention that the RFC itself says "you SHOULD NOT be a jerk about this". :-) So I don't think this is a big problem in practice, and I hope Steve can reconfigure the obstructive server to not be so picky.
To be clear the 'obstructive server’ is mailman-core. :)
[ec2-user@ip-172-31-18-xxx ~]$ telnet 172.19.199.2 8024 Trying 172.19.199.2... Connected to 172.19.199.2. Escape character is '^]'. 220 mailman-core GNU Mailman LMTP runner 2.0 LHLO ip-172-31-18-xxx.us-west-2.compute.internal 250-mailman-core 250-SIZE 33554432 250-8BITMIME 250 HELP MAIL FROM:<stephen.s.w.matsmats@gmail.com> 250 OK RCPT TO:<matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856@mm3.aca-aws.s.uw.edu> 553 5.1.3 Error: malformed address RCPT TO:<matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55@mm3.aca-aws.s.uw.edu> 250 OK quit 221 Bye
Didn’t really dig but my guess would be the LMTP from aiosmtpd.lmtp is actually throwing the 553.
For a bit of context, of the 25,801 mailman2 lists we have here at University of Washington 5,211 have names longer than 15 characters (we don’t have any lists with multibyte characters in their names). Our longest list name is 33 characters. I didn’t dump every config to see the number of lists that subscribe_policy set to confirm or confirm and approve. But I expect it’s a small minority.
steve
For Mailman, I doubt we need a full SHA1 (?) for the purpose. We can truncate the thing, probably opportunistically (ie, so the whole confirmation mailbox fits in 64 octets, or we could even parse the bounce message and resend only if we run into a problem).
Steve
Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-leave@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
On 2/28/21 1:07 PM, Stephen Mats Mats wrote:
To be clear the 'obstructive server’ is mailman-core. :)
[ec2-user@ip-172-31-18-xxx ~]$ telnet 172.19.199.2 8024 Trying 172.19.199.2... Connected to 172.19.199.2. Escape character is '^]'. 220 mailman-core GNU Mailman LMTP runner 2.0 LHLO ip-172-31-18-xxx.us-west-2.compute.internal 250-mailman-core 250-SIZE 33554432 250-8BITMIME 250 HELP MAIL FROM:<stephen.s.w.matsmats@gmail.com> 250 OK RCPT TO:<matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55856@mm3.aca-aws.s.uw.edu> 553 5.1.3 Error: malformed address RCPT TO:<matsmats-mm3-test1-confirm+d6f77a2572ef55a8b2c4ca0d77de8493fbb55@mm3.aca-aws.s.uw.edu> 250 OK quit 221 Bye
Thanks for the info. I'll investigate further.
It looks as though the LMTP runner (server actually) is responding with the 553 and then the sending MTA is retrying with a truncated local part, but of course that doesn't work because the token won't be found.
I will look at trying to convince Mailman's LMTP to accept the longer local part or barring that to get the confirm command to accept the truncated token.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 2/28/21 5:36 PM, Mark Sapiro wrote:
I will look at trying to convince Mailman's LMTP to accept the longer local part or barring that to get the confirm command to accept the truncated token.
I have filed <https://github.com/aio-libs/aiosmtpd/issues/257>. I will also file an issue for Mailman core at GitLab, but GitLab is not cooperating at the moment.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Just to complete this thread, the GitLab issue is https://gitlab.com/mailman/mailman/-/issues/836. The issue is fixed in aiosmtpd 1.4.1 and the solution for Mailman is to upgrade aiosmtpd to 1.4.1 or later.
participants (4)
-
Mark Sapiro -
Stephen J. Turnbull -
Stephen Mats Mats -
Stephen Willey Mats Mats