This page is out of date, please use our new website https://surgemail.com
Some definitions to start with:
Bounce = Sending an email to a sender to tell them the delivery failed
Reject = Rejecting an incoming message (this may result in the sender receiving a bounce, but one is never sent by your system)
Drop = The message is thrown away, the sender will not know that the delivery failed.
In some situations surgemail will drop a message instead of generating a 'bounce' email.
- It will generate a bounce email if the sender is a local domain
- It will generate a bounce email if the sender was spf verified (even by the default spf record)
- A 'bounce' is not needed if a 'reject' occurs. Surgemail always tries to reject an incoming message so very few bounces occur.
- If none of the above applies, then the bounce is dropped instead of sent.
Why? Because spammers use forged 'from' addresses, and bouncing a message to a forged address is a form of spam. The person receiving those bounces will very likely report your server and it will end up black listed by spamcop and similar RBL services. This problem is very hard to track down once it occurs, particularly on a large server, many customers were affected by this and being continually black listed.
In what situations do 'real' emails get lost due to these settings?
Settings I can use to avoid this problem.
First and most important, on secondary / backup mx servers you should use this setting:
g_gateway_data "true" (this requires 3.7b-7 or later)
This means that when gatewaying the message is sent during the 'data' stage so that if it bounces the incoming email can be correctly rejected so that the sender is informed by no 'email' bounce is generated.
Alternatively you can use this setting to forward these bounces to a responsible person to check them:
g_bounce_redirect "bounces@your.domain"
Lastly, if you are not worried about being black listed by an rbl site you can use this setting to restore the original behaviour.
g_bounce_nodrop "true"