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
net_smtp: Allow 5xx errors and bounces to be inhibited per-recipient.
If sender A sends an email to mail service B, where a user has
configured forwarding to a secondary account at mail service C, if
server C rejects the message for whatever reason (e.g. explicit reject,
DMARC failure, etc.), a bounce will go back to the original sender, A.
This is typically because C rejects the message at transaction time, in
which case B receives the rejection while trying to forward, and in
turn triggers a bounce to A; however, even if we reject after
transaction, if B did not use SRS, the original return path would be
unmodified and thus the bounce would go back to A.
This may be undesirable for several reasons. It causes confusion to the
original sender, since the message may well have been delivered
successfully to B, yet she receives a bounce nonetheless. More
importantly, this kind of indirect bounce, while "normal" in SMTP, may
leak sensitive information, such as the address at C to which messages
are being forwarded, or even the fact that messages are being forwarded
from B in the first place. None of this is the sender's business.
In the case where we are acting as server C, we can take action to
prevent this behavior by allowing bounces to be inhibited towards the
original sender. Assuming a unique email address is used for forwarding
messages from B --> C, we can prevent 5xx errors or bounces for
transactions involving these addresses, ensuring that as far as B is
concerned, the message was delivered successfully, even if it was not
(users could choose to manually send the bounce to the mailbox at B,
which should not be forwarded back to C again because it's a DSN;
however, the bounce could also be sent to any other arbitrary mailbox).
A crash fix is also included; inside expand_and_deliver, we were
previously passing a pointer rather than the address of the pointer,
resulting in a crash when we tried setting it. In all other places
where we call smtp_run_delivery_callbacks, we have a void** we pass
in; the variable is stack-allocated at this call site (void*), so
we need to pass its pointer. This wasn't flagged by the compiler as
gcc won't (and shouldn't) complain if you try passing a void* to a
function expecting a void**.
LBBS-137 #close
Copy file name to clipboardExpand all lines: configs/net_smtp.conf
+21Lines changed: 21 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -199,3 +199,24 @@ loglevel=5 ; Log level from 0 to 10 (maximum debug). Default is 5.
199
199
;
200
200
;john = john@example.com,*@john.example.net ; Allow local user 'john' to submit outgoing mail additionally using john@example.com or *@john.example.net
201
201
;jane = * ; Allow local user 'jane' to submit outgoing mail using ANY identity (DANGEROUS!)
202
+
203
+
[bounce_redirects] ; Inhibit 5xx replies and bounces for messages to specified recipients.
204
+
; This is intended for use with email addresses that are the target of forwarding/redirects from other mail servers,
205
+
; i.e. the sender A sends a message to a recipient at mail service B, which forwards messages to C (this server).
206
+
; If a permanent failure occurs, normally we will ideally respond with a 5xx SMTP error code at transaction time, or potentially send our own bounce message.
207
+
; However, this can be confusing to sender A, because in the case of a message rejected during the B --> C transaction, B will
208
+
; generate a bounce back to sender A. This is misleading and problematic, for two reasons:
209
+
; 1. Sender A sent a message to B, which may well have successfully received the message in user B's inbox there. It's only the additional forwarded copy that failed.
210
+
; 2. This may leak sensitive information, i.e. the fact that messages are being forwarded from B to C, including the forwarding address.
211
+
;
212
+
; Even if we do not reply 5xx during the transaction, if we later send a bounce and B did not use SRS (Sender Rewriting Scheme), the bounce
213
+
; would still end up going to the original sender if the MAIL FROM sender was unaltered, so this may also lead to undesired bounces going to A.
214
+
;
215
+
; For these reasons, the recipient at B may wish to prevent bounces of this type from going to the sender in the first place.
216
+
; We can do this by ensuring we always reply 250 OK during the transaction, and send a copy of the bounce to a different address, if desired.
217
+
218
+
; For example, suppose John Smith forwards his messages from jsmith@example.net to forwarded-jsmith@example.com (a unique address only used for forwarding purposes).
219
+
; This rule will ensure that we do not cause senders to receive bounces for messages (directly or indirectly) for such forwarded messages,
220
+
; and instead will send a copy to some other recipient (this could be any arbitrary address, including the forwarding mailbox, though take care not to create a loop.)
if (no_sender_bounce) { /* At this point, all recipients have been consumed, so we can't use dont_bounce_to_sender(), we need to check this flag */
2828
+
smtp_reply(smtp, 250, 2.6.0, "Message accepted for delivery (not really)");
2829
+
bbs_smtp_log(2, smtp, "Message from <%s> rejected in full by custom policy: %d %s %s (responded 250; not bouncing to sender)\n", smtp->from, resp.code, resp.subcode, resp.reply);
2830
+
/* resp.code is set, so no need to lie and set succeeded (to avoid default failure reply) */
2831
+
} else {
2832
+
bbs_smtp_log(2, smtp, "Message from <%s> rejected in full by custom policy: %d %s %s\n", smtp->from, resp.code, resp.subcode, resp.reply);
0 commit comments