Chris-Linfoot.net

1. For this to be an effective spam vector, an intermediate relay is required that a) accepts email on behalf of the target domain and b) does not check the directory at the target domain to ensure that intended recipients exist. It will therefore accept email to non-existent recipients and return it if it bounces. Thus:
   
   
   • The spammer sends to <nonexistentuser@someplace.example> and spoofs the sender as <victim@yourplace.example>.
     
     
   • The intermediate relay accepts the message, but the destination system responds with "550 no such user" when the intermediate relay tries to deliver it.
     
     
   • The intermediate relay then creates an NDR and sends it to the purported sender of the original message.
   
   As the intermediate relay is probably not listed on any DNSBL being used at yourplace.example, the sender envelope of the NDR is null (per RFC requirement) and the recipient envelope of the NDR is a valid local recipient, that recipient (victim@yourplace.example, remember) receives the spam in the form of a non-delivery report.
   
   
2. This just isn't a problem here. Virtually all spam comes direct-to-MX (2) now that the era of the open relay is over and I cannot recall the last time I saw any spam delivered, whether to a user or a spamtrap, in the form of an NDR. However...
   
   
3. It is a common virus vector. Why? Because a) where spammers often spoof a sender domain without taking care to spoof a valid sender address, viruses always use live email addresses as both sender and recipient and b) there are just so many of them.
   
   But any AV system at your inbound gateway that is worth its salt (3) will spot viruses in NDRs just as in any other type of message and you can and should also filter known bad file types in all messages.

And that would have been that but before I got around to writing this piece, Tajuanda got back in touch with a solution in the form of an enhanced mail rule.

When form contains NonDelivery and X-Mailer does not contain Notes Release 6.5.1 don't accept message

Obviously you would need to tune it to whatever version or versions of Notes are in use in your organisation or just omit the numeric parts of the mailer.

This is so simple and for pure Domino shops is pretty safe (4).

If an NDR comes in and the mailer is purported to be anything other than Notes (5), then it is bogus and may be rejected. It may not save you from a lot of spam unless you are unfortunate enough to have your own email address forged as the sender of a large spam run but it will keep viruses and most virus backscatter out.

Well done Tajuanda.

Notes:

1. the term RNDR is somewhat redundant (Reverse Non-Delivery Report) as an NDR is by definition sent via the reverse SMTP path to the purported originator.
   
   
2. If you use MX fallback then another vector could be email sent from your domain to your domain and submitted via the fallback MX. Another reason not to use MX fallback.
   
   
3. I do know of one AV system which, prior to being patched, actually did ignore NDRs on the grounds that having sent these messages in the first place it already knew them to be virus free and didn't need to look again when they bounced. To save embarrassment, I will not name it here but I do urge you to keep your AV system up to date - not just signatures but the software too.
   
   
4. If you have non-Notes software submitting messages via your Domino servers (including iNotes), then you will need to tune this rule carefully.
   
   
5. Spammers very rarely forge Notes as a mailer. They like Outlook, Outlook Express, The Bat! and Apple Mail. Viruses never forge Notes as a mailer. They do sometimes invent a completely new one though.

Category: Domino: Administration
Technorati: Domino: Administration

1. Chris25/07/2006 14:54:43

Hi,

Any idea how you would go about stopping this RNDR if you domino server where the "intermediate relay" ?

br,
Chris

2. Chris Linfoot25/07/2006 15:17:18

Not sure I understand the question - but if I do, then you would just do exactly what is documented here.

3. Chris R25/07/2006 15:55:38

I guess the problem is that I get the message on to the message queue, then it it's discovered that the user does not exist and the message is RNDR'ed , or what ever the correct wording is, to an unlucky 3.party.
I would rather that this did not happen also I would like the delivery failure reports to work. Is my option then to check if the user exists before he is accepted to the queue, and how is that actually done ?, or is there any other things that could be done ?
This is not my usual area, so I am trying to learn a little

4. Chris Linfoot25/07/2006 16:20:00

OK I get it. Spammer sends mail to a non-existent user at your domain "from" some luckless bystander. Your server accepts it, can't find a local user matching the local part of the address and creates a bounce. Bounce goes to luckless bystander.

Am I right?

If so, you can defeat this completely just setting the server config document field "Verify that local domain recipients exist in the Domino Directory:" to "Enabled".

Now when spammer sends to non-existent user at your domain, your server will never accept the message in the first place, so there's nothing to bounce later.

5. Chris26/07/2006 15:16:05

I changes some settings today, so that the check local domain recipients is enables, and just to make the NDR situation more visible I turned of the hold undeliverable mails, they would other wise go out as NDR's.
So what seems to be happening is that mails without valid recipients is rejected in the initial SMTP conversation, which is good. But the bad thing is that if there is multiple recipients, then it goes through to the mail queue - and this is actually what seems to be happening a lot. This is not really making me that happy, maybe one could make a rule to kill mails with a failure reason like "Several matches found in Domino Directory."...hmm

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