Chris-Linfoot.net

1. The IP address of the remote MTA connecting to deliver the mail
2. The resolved name of that IP, if it has one, or simply that fact that it has no resolved name.
3. The argument used by the remote MTA in the HELO/EHLO command
4. The reverse path (MAIL FROM:...) of the message
5. The forward path (RCPT TO:...) of the message

These 5 pieces of information are processed by the Domino MTA in the following ways:

1. The IP address.

a. "Allow messages only from the following internet hosts to be sent to external internet domains:" - permits that IP to relay
b. "Deny messages from the following internet hosts to be sent to external internet domains:(* means all)" - denies that IP relay capability
c. "Exclude these connecting hosts from anti-relay checks:" - exempts that IP from any anti-relay checking (use withe extreme caution)
d. Can be used in a DNSBL style look-up and that information used to block or tag a message coming from a spammy source.
e. "Deny connections from the following SMTP internet hostnames/IP addresses:" - denies that IP any access to SMTP whether to relay or to deliver mail to a local recipient

2. The resolved name.

a. "Allow messages only from the following internet hosts to be sent to external internet domains:" - permits that resolved name to relay
b. "Deny messages from the following internet hosts to be sent to external internet domains:(* means all)" - denies that resolved name relay capability
c. "Exclude these connecting hosts from anti-relay checks:" - exempts that resolved name from any anti-relay checking (use withe extreme caution)
d. "Verify connecting hostname in DNS:" - denies mail from hosts that have no rDNS or badly configured rDNS; this is usually a bad idea as a large number of legitimate MTAs have broken rDNS (sometimes deliberately, often accidentally)
e. "Deny connections from the following SMTP internet hostnames/IP addresses:" - denies that resolved name any access to SMTP whether to relay or to deliver mail to a local recipient

3. HELO/EHLO

Not used by Domino at all. A remote host could say "HELO HELO HELO WHATS ALL THIS THEN" and Domino wouldn't blink.

4. The reverse path

a. "Verify sender's domain in DNS:" - verifies the right hand side of a sender's email address; could a reply to this address work (that is, does the sender's domain have MX or a host with that name)?
b. "Allow messages only from the following external internet addresses/domains:" - kind of a white list for Internet domains. This is not very useful as sender envelopes are easily spoofed.
c. "Deny messages from the following internet addresses/domains:" - a black list of sender domains/addresses. Somewhat useful as a last resort but limited due to the ease with which sender envelopes are spoofed. However, list all of your own local domains here and this does defeat a common spammer trick as well as some viruses which pretend to be "from" a local sender.

5. The forward path

a. "Verify that local domain recipients exist in the Domino Directory:" - the Domino MTA will respond with "550 no such user" if there is no user in the Domino Directory that matches the forward path. This is useful because otherwise spam to non-existent users, which cannot be bounced due to a forged sender envelope will accumulate, dead in mail.box. It does open users up to dictionary attacks though.
b. "Allow messages intended only for the following internet addresses:" - prevent all but named local users from receiving any Internet mail.
c. "Deny messages intended for the following internet addresses:" prevent named local users from receiving any Internet mail.

The most useful of these to the Domino spam fighter are:

1d - DNSBL
1e - a local block list to block IPs or contiguous ranges of IPs regardless of resolved name
2e - a local block list to block hosts based on resolved name regardless of IP - useful against trojaned proxies on DSL connections
4a - denies obviously bogus senders
4c - last resort block list based on apparent sender; also very useful to keep out spam and viruses which spoof the sender as someone local (MAIL FROM:<fred@example.com>, where example.com is your local Internet domain and fred may or may not be a real user there)
5a - accepts mail only for real people and keeps mail.box free of dead, undeliverable spam

The glaringly absent features are:

1. The DNSBL whitelist. I have written about this plenty of times previously, so will not go into this again here.
2. Any kind of checking on HELO/EHLO

HELO/EHLO checking

A strange omission in what is otherwise a powerful MTA. Even badly configured hosts sending bona fide email will HELO with something that looks like a non-local, fully qualified host name (whether or not that name actually resolves).

A very common spammer tactic is to play tricks with HELO to try and throw victims off the scent. Typical tricks are:

• HELO 10.0.0.1 (or any other RFC1918 reserved address) to try and give the impression that spam originated in the local Intranet
• HELO mail.example.com (where mail.example.com is your own MTA)
• HELO example.com (where example.com is your own local Internet domain)
• HELO 240.12.23.34 (where 240.12.23.34 is the IP address of mail.example.com, your own MTA)
• HELO webserver (not a fully qualified host name, these are almost always hosts being abused via a trojan or an insecure script running locally, for example formmail.pl)
• HELO compuserve.com, HELO aol.com and variations on that theme (to try and implicate some third party, usually a large ISP)

It is perfectly sensible for any MTA processing HELO/EHLO to offer the option to drop mail from

• any host that HELOs with an IP address
• any host that HELOs with a local host or domain name
• in many cases, any host that HELOs with any string other than a non-local FQHN (fully qualified host name)

But Domino does not yet do this. Possibly another reason to consider Sendmail as the inbound gateway in the DMZ.

Category: Domino: Administration
Technorati: Domino: Administration

1. airplay19/08/2003 15:01:09
Homepage: http://utle.com

I haven't really struggled to configure my servers right, but you really put everything so nicely in context! Systematically and RFC-referenced all the way. I've recommended your article(s) to more than one colleague.

Thanx!

//airplay (aka Trond-Are Utle)

2. Chris Linfoot19/08/2003 16:14:49

You're very welcome

3. Ed Falcon20/08/2003 18:06:14
Homepage: http://www.madjunk.com

I agree with "Airplay". Great job on the detail Chris...I appreciate the effort you put behind your posts. Just the type of stuff I was looking for when I launched my site.
Keep up the good work.

Ed

4. MHelm12/09/2003 16:29:21

Looks like someone finally developed that whitelist capability for you!

http://www-10.lotus.com/ldd/46dom.nsf/DateAllThreadedweb/60814ea1927df0d885256d9f00474970?OpenDocument

5. Chris Linfoot13/09/2003 09:41:49

Sadly not

Don't misunderstand me. I think Raymond has done an outstanding job and made the very best use of the toolkit available but...

There is no way to hook the SMTP listener in the Domino server. So his extmgr_addin has to hook the mail router, just like a virus scanner would.

This means that the entire spam email has to be accepted by the SMTP listener and handed over to the mail router so that Raymond's excellent addin can do its work.

This rules out protocol level blocking.

As we now turn away c. 50-60% of all Internet email at the protocol level, and a very high and increasing proportion of this comes from dynamicaly assigned addresses with trojaned home computers on the end, there is really no need to accept this stuff, just to "block" it afterwards at the mail router. Avoids wasted bandwidth etc.

So that is the main architectural issue here which a mail router addin cannot hope to address.

There is also the point that true whitelisting saves DNS lookup overhead at the Domino server, because we do not need to look up hosts we trust and these account for over 50% of all emails we accept. Raymond's addin will still generate DNSBL style DNS lookups for every email received - that's how it works.

So the need for a Domino whitelist stands. Raymond has produced a very effective workaround (hats off for a good job well done) which may be suitable for many people, but I can't use it here.

6. Chris Linfoot13/09/2003 09:48:30

Paging Raymond Neeves.

QV last post here by me. Am I wrong? Is there a way to hook the SMTP listener and do SMTP black/whitelisting at the protocol level with an external addin?

I do hope I am wrong, trust me.

Thanks

cwl

7. Chris Linfoot18/09/2003 14:51:24

And it turns out, Maria was right and I was wrong...

http://chris-linfoot.net/linfoot/blogsphe.nsf/plinks/CWLT-5RECFT

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