You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If replace_rcpt introduces a mix of deliverable and undeliverable mail addresses for outgoing mail, the client will receive an error and might retry the delivery over and over, spamming all deliverable mail addresses.
Details
I'm running the digital infrastructure for a local sailing club, and recently tried to implement a simple mailing list using maddy and a replace_rcpt table. Mails to the alias can only be sent from internal addresses, but are sent out to external addresses.
On the first test run, inevitably some mail was rejected by remote servers, both with 4xx and 5xx status codes. Everybody else received an increasing number of copies of the same message, until I stopped maddy and cleared the remote queue. The sender also received a number of DSNs. As a result of this incident, multiple mail providers temporarily blocked mail from us.
Investigating the maddy logs revealed that the mail client (the Android Google Mail App) had sent a total of 12 messages to maddy, despite the sender insisting they only tried to send two messages. Apart from this, maddy behaved correctly. It only retried the delivery to recipients that previously failed to receive the message.
Interpretation
My guess is that the client received an error code from maddy, and this triggered repeated retries. Unfortunately I did not have debug logging enabled at the moment to tell exactly, and I'm hesitant to recreate the situation.
Thinking about this for a bit, returning an error code is correct behavior if the recipient did not receive the message correctly. But for rewritten recipients, I don't think this behavior is desirable if at least one recipient received the message, because it can lead to situations as described above. A DSN should be sufficient. At a glance, internal/modify/replace_addr.go does not seem to be handling this case specially, so I'm somewhat confident this is the root of the issue.
If changing the current behavior is deemed undesirable by the maintainers, I would at least urge to put a prominent warning on the documentation of the replace_rcpt module, as the consequences of this interaction can be considerable, up to possibly landing the server on spam block lists.
Steps to reproduce
Use replace_rcpt to rewrite the recipients of outgoing mail, with a 1:n mapping that includes some undeliverable addresses.
Log files
My analysis of the logs can be found above. I'm hesitant to upload them outright as they contain a lot of personal info from other people.
Non-debug logs should be enough to determine if the sender received any error from maddy - look for "submission: DATA error", "RCPT error", etc.
Note that target.queue won't produce an error on initial delivery if the message can't be delivered to some addresses - if the message is enqueued successfully, the sender will see "OK" status.
Okay, now I am completely stumped, and have to apologize for jumping to conclusions. The log contains no such lines (I'm guessing "submission: accepted" denotes a positive response?). But why on earth would the client then try to retransmit the message?
I went through the process of anonymizing the log file, and hope this contains no more personally identifying information. It can be found here. Does this help?
Describe the bug
If
replace_rcpt
introduces a mix of deliverable and undeliverable mail addresses for outgoing mail, the client will receive an error and might retry the delivery over and over, spamming all deliverable mail addresses.Details
I'm running the digital infrastructure for a local sailing club, and recently tried to implement a simple mailing list using maddy and a
replace_rcpt
table. Mails to the alias can only be sent from internal addresses, but are sent out to external addresses.On the first test run, inevitably some mail was rejected by remote servers, both with 4xx and 5xx status codes. Everybody else received an increasing number of copies of the same message, until I stopped maddy and cleared the remote queue. The sender also received a number of DSNs. As a result of this incident, multiple mail providers temporarily blocked mail from us.
Investigating the maddy logs revealed that the mail client (the Android Google Mail App) had sent a total of 12 messages to maddy, despite the sender insisting they only tried to send two messages. Apart from this, maddy behaved correctly. It only retried the delivery to recipients that previously failed to receive the message.
Interpretation
My guess is that the client received an error code from maddy, and this triggered repeated retries. Unfortunately I did not have debug logging enabled at the moment to tell exactly, and I'm hesitant to recreate the situation.
Thinking about this for a bit, returning an error code is correct behavior if the recipient did not receive the message correctly. But for rewritten recipients, I don't think this behavior is desirable if at least one recipient received the message, because it can lead to situations as described above. A DSN should be sufficient. At a glance,
internal/modify/replace_addr.go
does not seem to be handling this case specially, so I'm somewhat confident this is the root of the issue.If changing the current behavior is deemed undesirable by the maintainers, I would at least urge to put a prominent warning on the documentation of the
replace_rcpt
module, as the consequences of this interaction can be considerable, up to possibly landing the server on spam block lists.Steps to reproduce
Use
replace_rcpt
to rewrite the recipients of outgoing mail, with a 1:n mapping that includes some undeliverable addresses.Log files
My analysis of the logs can be found above. I'm hesitant to upload them outright as they contain a lot of personal info from other people.
Configuration file
Environment information
The text was updated successfully, but these errors were encountered: