"Verify Connecting Hostname in DNS" in log and tag mode?

HCL Domino Domino Forum
1

As you all know, much SPAM would fail the reverse DNS lookup. But I am a bit wary of turning on the reverse lookup feature because of potential false positives.

First, what experience have people had turning the DNS lookup function on? Is there much risk to doing so?

Second, what do people think about asking Lotus to add the option of logging and tagging based on reverse lookups? We used this function with blacklists before we changed to log and reject (which works well, but still lets too much through).

TIA.

-Andy

2

Subject: duplicate - please ignore

3

Subject: “Verify Connecting Hostname in DNS” in log and tag mode?

There are three DNS tricks available to Domino admins during SMTP handshake:

  • the DNSBL feature

  • verify sender’s domain in DNS

  • verify connecting hostname in DNS

Taking the last of these first as that is where your interest lies…

Verify connecting hostname - do not use. Many, many administrators of SMTP MTAs of all flavours either knowingly choose not to have proper forward and reverse DNS, or else simply do not bother through ignorance or worse. This is undoubtedly bad manners, but use it as a check to decide whether to accept email or not and you will reject a lot of real email. Just did an analysis of sending hosts here yesterday (looking for candidates for a possible future white list) and 4 of the top 5 senders to this site have no DNS on their SMTP MTAs. Not worth tagging these even if you could, based on this - we would tag probably 40-50% of legitimate email this way.

Verify sender’s domain - very safe to use. It merely checks that the right hand side of the sender’s email address is available to send email back to (that is does the RHS of the sender’s address have a DNS A or MX record). If it fails this test, then you cannot reply to the message and it is safe to assume that legitimate senders want replies. A small number of spammers and viruses spoof something in the sender envelope which fails this test (e.g. Sobig.A sends from big@boss.com and boss.com exists, but has no A or MX record, so this feature keeps Sobig.A out of Domino servers).

Finally, note that when Verisign re-introduces the site finder system (wildcard A and MX records for .com and .net TLDs), then the verify sender’s domain in DNS feature becomes substantially less useful (and will no longer stop Sobig.A).

Chris Linfoot

4

Subject: RE: “Verify Connecting Hostname in DNS” in log and tag mode?

There are some Gotchas with “verify connecting Hostnames”. If you have any internal Pop3 clients connecting to your Domino server, you need to add them to your DNS server or the Domino servers hosts file.If you have external clients who get turned back, have them correct their DNS/SMTP MTA records. If they can’t or don’t know how, you can allow them access by putting their IP address in the “SMTP inbound Controls” “inbound relay controlls” “allow messages only from the following internet hosts to be send to external internet domains” Not the best practice, but it works. Remember to use this IP format “[xxx.xxx.xxx.xxx]”

5

Subject: what about SMTPVerifyAuthenticatedSender in notes.ini?

Thanks Chris. I turned on verify sender’s domain, but no discernable improvement.

But do you have any thoughts about the notes.ini SMTPVerifyAuthenticatedSender setting? The admin help entry makes this sound potentially helpful, because much spam would fail:

The SMTPVerifyAuthenticatedSender= NOTES.INI setting designates whether mail that is sent during an authenticated SMTP session must be from the Internet address of the authenticated users. The intent is to verify that the user is not attempting to spoof the “From” field. This feature is most useful when a Domino SMTP server is configured to enforce authentication, but that is not a requirement.

SMTPVerifyAuthenticatedSender has multiple values.

Syntax: SMTPVerifyAuthenticatedSender=value

Description: Specifies whether the SMTP server requires mail sent during an authenticated session to be from the Internet address of the authenticated user.

0 - Do not require the sender to use their Internet address

1- Require the Sender, or From, if Sender header does not exist, to match the Internet address of the authenticated server.

2 - Require the RFC822 From header to match the Internet address of the authenticated user. Sender is not checked, just From is checked

6

Subject: RE: what about SMTPVerifyAuthenticatedSender in notes.ini?

I wouldn’t expect much improvement with Verify sender’s domain, but it is also harmless, so very safe to use.

Here last month, we blocked a total of 20,102 inbound SMTP sessions using DNSBLs, local blocking and other checks including verify sender’s domain. Of those 20,102, precisely 64 (0.32%) were due to the failure of verify sender’s domain in DNS - but all were spam or viruses.

As for SMTPVerifyAuthenticatedSender, no use at all for normal SMTP mail being received from another MTA. This feature is for sites that want users with non-Notes MUAs (e.g. Outlook Express) to be able to receive (POP3 or IMAP) and send (SMTP) email.

You can require such users to authenticate for sending SMTP and, if you choose, relax relay restrictions on authenticated connections. Of course an increasingly common trick is for spammers to use brute force attacks against MTAs that permit unrestricted relay for authenticated users, to discover a valid username/password. These are then used by the spammer in the same way as a simple open relay.

See: Spamhaus and Google Groups.

SMTPVerifyAuthenticatedSender is an additional security feature that permits relay for authenticated users only when they use their real email address to send such emails. Of course, if the spammer knows this, he will just use that user’s real email address in his from field and the relay will still occur.

This is why I recommend that you either enforce relay restrictions for authenticated users – default behaviour in Domino, though not in Exchange – or you enforce a strong password policy for users who authenticate with SMTP.

In any case, as an anti spam tool, SMTPVerifyAuthenticatedSender is simply not an option. Remote MTAs will not attempt to authenticate (why would they?), except of course for those spammers I mentioned.

Chris Linfoot