Chris-Linfoot.net

554 Message rejected for policy reasons.

But you can modify this response to include both the IP address being denied by the Domino SMTP server and the DNSBL causing the denial.

You do this by creating a custom message containing %s twice. The first of these is substituted by the denied IP address and the second by the DNSBL for each rejection that happens.

So, for example, if your server config says the custom response is:

Your IP, %s, was found in the %s block list.

Then the remote system, when rejected, will see a response like this:

554 Your IP, 172.17.12.54, was found in the dnsbl.example block list.

Better than the default response, but you can go one better still.

There's nothing to stop you from using this feature to deliver, instead of a bald statement about a rejected IP, an opportunity to submit a request to be whitelisted. Here's how that goes.

1. Set up an application * on your Domino HTTP server

This application contains a) a form which can be posted anonymously and which has fields for at least IP and block list and b) an agent that runs after a form is posted and processes it as follows.

• Verify that a valid IP address has been posted and that the DNSBL named is one that you actually use.
  
  
• Append that IP address as a literal (i.e. enclosed in square brackets) in a Domino Directory group which is listed in the Private Whitelist Filter section of your server's configuration document, in the field "Whitelist the following hosts:" This has the effect of whitelisting the rejected IP.
  
  
• You could modify the logic of this, so that only IPs blocked by certain DNSBLs are considered for automatic whitelisting, and the rest are submitted for administrative review. So, for example, you might choose to whitelist automatically an IP blocked as a result of a Spamcop listing, but to hold for review an IP blocked by Spamhaus Zen. This reflects the fact that Spamcop false positives are not infrequent, where Spamhaus Zen false positives are all but unheard-of.

You can pass parameters into this application via the URL using the technique described here.

2. Modify the custom SMTP error response for rejected messages on your Domino SMTP server

Instead of

Your IP, %s, was found in the %s block list.

make it

Your email appears to be spam. Please use this link to report errors - http://domino/app.nsf/form?OpenForm&ip=%s&list=%s

Here, we have used the custom SMTP error response to build a URL which the recipient of the bounce message can click to submit a whitelisting request.

• domino would be the qualified hostname of your Domino HTTP server
• app.nsf is the Domino application referred to in 1 above
• form is the form referred to in 1 above
• and the rest is self explanatory

Now, when a remote connection is rejected, the bounce message will be:

554 Your email appears to be spam. Please use this link to report errors
 - http://domino/app.nsf/form?OpenForm&ip=172.17.12.54&list=dnsbl.example

On those rare occasions when a real person sees one of these messages, now all s/he has to do to appeal against the block is to click a link.


* ND8 application == ND7,6,5... database.

See also: Identifying DNSBL false positives

Category: SnTT
Technorati: Domino Show-n-Tell+Thursday ShownTellThursday SnTT Whitelist

1. Charles Robinson11/12/2007 15:56:16
Homepage: http://cubert-codepoet.blogspot.com

Are you actually sending a NDR for spam? I thought the preferred approach was to not backscatter.

2. Kerr11/12/2007 16:12:31

@1, I think this is the rejection message that is returned when the server declines to accept the message, not an NDR.

3. Vitor Pereira11/12/2007 16:17:57
Homepage: http://www.vitor-pereira.com

Yeap, this is not and NDR. This is a protocol error, right? It then depends on the sending server passing it back to the user if there is a real one.

4. Chris Linfoot11/12/2007 16:25:27

Thanks @2 and @3 for answering @1's question.

Yes, this is not an NDR. It is the protocol response to a rejected session. This will either die at source (almost all real spam) or will cause an NDR to be generated by the remote system. In the latter cases, because most email is now sent directly from an MTA under the control of the sending party to the MX of the receiving party, the NDR will land in the right place - the in-box of the person whose email was rejected. There, s/he will see your self service link.

We have done this because our previous method relied on the remote sender copying and pasting the rejection text into a web form and remote senders would frequently just make something up or copy the example text from our whitelist submission page and submit that.

This way we can be relatively sure that the IP nominated for whitelisting is the right one, although we have not implemented the self service part at all here - every case is subject to review by an administrator.

5. Peter von Stöckel11/12/2007 21:37:55
Homepage: http://www.bananahome.com/

I have thought about doing this for some time now, but haven't gotten around to it yet. Too much other stuff to do, as always. It is good advice, though, and should also make it possible to use stronger black-listing.

Unable to post a comment? Please read this for a possible explanation...