bounce VERP & 553 Localpart too long

manusfreedom commented 3 years ago

Unable to send bounce notification because the from address localpart is too long (>64 characters).

Version

6.2.56

Installation method

Source package

Expected behavior

Mail notification must be send and don't block all next e-mails..

Actual behavior

Unable to send notifications to the user and the user does not receive any more emails after it starts. Each time the bounce+aaaaaaaaaaaaaaaaaa==a==rrrrrrrrrrrrrrrrrrrrrrrrrrr==ddddd-divers==5288513@ddddd.org is more than 64 characters many servers refuse the e-mail, because they follow RFC 2821 (https://www.ietf.org/rfc/rfc2821.txt). This is legitimate.

Additional information

Apr  2 14:53:49 server02 postfix/pickup[17082]: E3DF57D549AD: uid=1005 from=<bounce+aaaaaaaaaaaaaaaaaa==a==rrrrrrrrrrrrrrrrrrrrrrrrrrr==ddddd-divers==5288513@ddddd.org>
Apr  2 14:53:49 server02 postfix/cleanup[17143]: E3DF57D549AD: message-id=<AM5P190MB0451FFB7A742FCA5F817DD19957B9@AM5P190MB0451.EURP190.PROD.OUTLOOK.COM>
Apr  2 14:53:49 server02 postfix/qmgr[18803]: E3DF57D549AD: from=<bounce+aaaaaaaaaaaaaaaaaa==a==rrrrrrrrrrrrrrrrrrrrrrrrrrr==ddddd-divers==5288513@ddddd.org>, size=22739, nrcpt=1 (queue active)
Apr  2 14:53:50 server02 postfix/smtp[16460]: E3DF57D549AD: to=<aaaaaaaaaaaaaaaaaa@rrrrrrrrrrrrrrrrrrrrrrrrrrr>, relay=mx.email-control.orange-business.com[90.84.193.28]:25, delay=0.63, delays=0.31/0/0.13/0.18, dsn=5.0.0, status=bounced (host mx.email-control.orange-business.com[90.84.193.28] said: 553 Localpart too long (in reply to end of DATA command))
Apr  2 14:53:50 server02 postfix/bounce[16995]: E3DF57D549AD: sender non-delivery notification: 42C437D549B8
Apr  2 14:53:50 server02 postfix/qmgr[18803]: E3DF57D549AD: removed

ikedas commented 3 years ago

IMHO It seems unlikely that this can be fundamentally resolved. See also an example with the other software (PostSRS): roehling/postsrsd#108 .

Anyways we’d be better to file this problem as the bug.

manusfreedom commented 3 years ago

@ikedas See my commit on my repo. I am not a Perl developer and this commit is not tested. I just wanted to find a quick solution (but maybe too dirty). I will try to test it, but I only have a production environment.

ikedas commented 3 years ago

In Sympa::Spindle::ProcessOutgoing there are four use cases of get_bounce_address(). I see your fix try to improve the case with envelope ID: https://github.com/sympa-community/sympa/blob/39e3006ad6c948dba9e8322f9d5a5823ff2d727b/src/lib/Sympa/Spindle/ProcessOutgoing.pm#L256-L256

Currently, VERP for a user mailbox@user.dom.ain in the list local@list.dom.ain with envelope ID 99999999 is:

bounce+mailbox==a==user.dom.ain==local==99999999@list.dom.ain

IMO, in your fix in above, if the local part of this address is longer than 64 octets, it will be changed to

bounce+99999999==a====local==99999999@list.dom.ain

If it is not right, please tell me the result you expected.

manusfreedom commented 3 years ago

I fixed my code after some testing on my production environment. And yes, it is right. This code now works and has solved the main problem for me.

manusfreedom commented 3 years ago

@ikedas Please see the latest version/commits of https://github.com/manusfreedom/sympa/tree/fix-1160

ikedas commented 3 years ago

I got it. Indeed, for tracking, original recipient address may not be encoded in the VERP address: Envelope ID is suffice. Why don't we make it shorter? Such as:

bounce+local==99999999@list.dom.ain

manusfreedom commented 3 years ago

It can be, but I wanted to keep the same structure as before (with the 'who' part), so that the logs in postfix remain the same (easier when search with the current address structure).

The best solution would be to have an unique Id (integer) for each user and use it for the who part on all bounce types.

ikedas commented 3 years ago

@manusfreedom , I'm absent in the next week, so I'll work on the modification of Sympa based on the work you'll have done on your fix-1160 branch. Thanks!

ikedas commented 3 years ago

@manusfreedom , I investigated your chages, and found that there are a few difficulties:

As a result of your changtes, the database will be accessed every time any message is sent to the bounce+... address. That is, the attackers might launch a successful denial-of-service attack.
- As the VERP addresses for tracking will consist only of the list name and envelope ID by your cfhanges, it is easy to fake them: The attackers can post the messages with fake address to break tracking information.

In conclusion, I think, it seems that shortening the address is harmful.

manusfreedom commented 3 years ago

@ikedas So you conclude that it is better to have protected software than usable software?

I did not want to modify too much Sympa to solve this problem, but a solution is required to respect the RFC. If you need a hash (or equivalent) instead of the id, we need to modify the database or store using a file. And we can't use the user's email because it can directly use the character limit of the RFC.

ikedas commented 3 years ago

@ikedas So you conclude that it is better to have protected software than usable software?

I did not want to modify too much Sympa to solve this problem, but a solution is required to respect the RFC.

How about making the fixed part shorter? In the other words, set bounce_email_prefix parameter to a shorter one, e.g. "b":

b+mailbox==a==user.dom.ain==local==99999999@list.dom.ain

This will improve the situation at least partially.

If you need a hash (or equivalent) instead of the id, we need to modify the database or store using a file. And we can't use the user's email because it can directly use the character limit of the RFC.

Logically, the length of the "hash" cannot be shorter than the sum of the recipient address and the envelope ID, because we cannot reduce the amount of information.

On the other hand, if we could reduce the amount of information, i.e. using shorter address, Sympa would be vulnerable to DoS and DSN forgery attacks, as I mentioned in above.

sympa-community / sympa