Domino on Linux/Unix, Troubleshooting, Best Practices, Tips and more ...

Non Delivery SPAM

Daniel Nashed  22 February 2009 15:30:23

In the last couple of days I got a lot of SPAM which did not get blocked thru SpamGeek. Previously most non-delivery reports (NDR) have been filtered thru grey listing but not in this case. The following gives a quick info what you can do to prevent those kind of SPAM and more important how you can ensure your server is not sending non-delivery SPAM.

How does this happen?

In case your mail server does not check the recipient when accepting the message at the entry point of your domain (server where the MX records point to) another server inside your domain might bounce the mail as a NDR.
If this is a correct message bouncing would be a good way to inform the sender. But in case the sender is faked your server bounces back the message to the wrong sender and becomes a SPAM sender!


What should be done on all gateway servers?

You have to make sure the server which is responsible for your Domain does check the recipient and reject the message instead of bouncing it.

In case you have a relay host or an appliance in front of your Domino server this server needs to lookup the recipient in Domino.
If your Domino server is the first server that a mail hits in your environment (MX record) you should enable the following setting:


Router/SMTP --> Restrictions and Controls --> SMTP Inbound Controls
Inbound Intended Recipients Controls
Verify that local domain recipients exist in the Domino Directory:Enabled


This is really a requirement for all environments. But now what can we do for fake NDRs hitting our environment?



Bounce-Address-Validation-Tag-(BATV)

In case you have a server supporting the Bounce-Address-Validation-Tag-(BATV) you can enable this feature to ensure you can distinct between own and fake NDRs.
Ironport is one of the first vendors supporting a bounce verification option. See the reference website: http://mipassoc.org/batv/ for details.
What this feature does is to add a tag to the RFC821 from like this

MAIL FROM:<prvs=1234abba0=john.doe@acme.com>

The hash added to the from with the "prvs" tag can be verfied only by the server which sent the mail.
This is also good to know if you receive mail containing this tag because some anti-spam tools might interpret this from format as invalid.


SpamGeek Approach

Implementing BATV would be one option. But than I would need to ensure that outgoing messages need to get the same tag and I would need a EM hook also for outbound mail.
A more simple approach is to check inbound NDRs and other bounce mails for information that can be only in messages you have sent.

serialized := "Serialize by Router on "+@name ([ABBREVIATE]; @username);
@if ((Mail_Form = "NonDelivery Report") | (@Contains(@lowercase(From); "mail delivery":"mailer-daemon"));
@if ((@Contains ($MIMETrack; serialized) | @Contains (BodyTextAbstract; serialized)); 0; 1); 0)

This reduced fake NDRs in my environment to zero :-)


Conclusion

Even if you don't get fake NDRs you should carefully verify if your are rejecting messages with invalid recipients to avoid distributing SPAM and to be black-listed.

-- Daniel
Comments

1Karsten Lehmann  05.03.2009 1:35:36  Non Delivery SPAM

As reported at Entwicklercamp in Gelsenkirchen, I'm having some problems with emails that get forwarded to my company email account from GMX (an old private mail account). Some emails go through the GMX text filter and then also directly through SpamGeek, because the GMX host is considered a "good sender" (because most mails coming through GMX are ok).

Maybe you have an idea for this problem for later release of SpamGeek, like taking hosts like GMX out of the grey listing.