Topic: Drop e-mails from non-existent domains

[KelvinLee]

Is there a setting / way to get SME to drop mails / SMTP connections purporting to be coming from non-existent domains ?

Also, is there a way to reject mails coming from IP addresses that do not have Reverse DNS setup as well ?

Thanks.

Kelvin

[raem]

Perhaps the greylisting contrib from Gordon Rowell may achieve the end result you are after (getting rid of junk email from fake addresses), although it does not use the techniques you ask for.

http://lists.contribs.org/mailman/public/devinfo/msg07912.html

[KelvinLee]

Hi Ray,

Interesting concept. However, for the few clients asking for the original solution, the delay introduced by the Greylisting method would be totally unacceptable.

We are talking about people near the very top of the company expecting e-mails practically as soon as the sender hits the send button, and they have been too accustomed to getting mails this way to accept a delay. One guy's comment was "I might as well go back to using faxes !". Well, OK, he actually said a lot more.... but bleeping it out would render it unreadable !  

Kelvin

[raem]

Kelvin

The comments you mention are EXACTLY those that were said to me when I implemented greylisting at a site.

I would ask though, how do you or the end users know that the delay would be "totally unacceptable". You only have a surface knowledge of how greylisting works in practise (ie you believe that it delays every message & therefore that is a bad thing). What was that famous phrase, "A little knowledge is a dangerous thing".

I would strongly suggest that your users are unlikely to notice any difference (or very little difference) for a variety of reasons.

I tried it myself on my own server (low volume email). I also persuaded another site (moderate volume) to conduct a test as they were quite alarmed at the possibility of not receiving messages "immediately" (I'm sure you know that there is nothing immediate about email as it can be quite slow at times, so I feel their concerns were not totally correct anyway).

I DID NOT tell them when it was introduced, I just installed it. I received NO complaints at all over a one month period.
During that month spam dropped to virtually zero (RBL, pattern matching & bad HELO/EHLO were also in effect & doing their job quite well). This server is rejecting (at smtp level) about 7000 "bad" messages every month.

I would say that the above 3 techniques do reduce spam to quite low levels, but greylisting got rid of the ones that slipped through.

Greylisting remembers the sender IP and only the first message is delayed (in a specified & adjustable period, normally 24 hours). Subsequent messages from the same sender in the same period do not get delayed, they are delivered as normal.

Furthermore you can create white lists of IPs and those senders NEVER get delayed. Add your local IP and other trusted IPs to totally avoid delays from those senders. You can also add IPs from common trusted senders and over time build up a popularly used list of IPs for which no greylisting will occur.

In practice both of the above means a lot of messages are NEVER delayed.
It would depend somewhat on your pattern of usage, ie whether lots of different senders or regular repeat senders and how much effort you want to put into whitelists.

If any email users have already received one message from a sender today (same IP) (default setting), then all other messages will be delivered as normal with no delay.

Of course on the downside there are some other issues, primarily broken mail systems that do not retry (as greylisting relies on the retry for the message to get through), then it is possible to loose messages from mail servers that do not retry.
When you find out (probably by a complaint from the sender) you can add that server IP to the whitelist and all messages from them will be delivered without delay. A majority of mail servers do retry.

You could say that a similar (but different) problem of (undelivered messages) applies to the use of RBL lists, but a lot of us are happily using those.

The other problem area is where there are server banks with multiple IPs sending the same message. It gets greylisted with the first IP, then greylisted with the second IP then the 3rd & 4th etc, hopefully it then tries using the first IP and will then get successfully delivered. I have watched this happening in logs on my own server, eventually the message is delivered, the actual delay will relate to the frequencey of retries. Again in practise this was not great as the message was from a large corporate who kept retrying every few minutes, so the message got through after about 10 - 20 minutes any way. Note that some ISP's retry after 30 - 60 minutes and some other ISP's eg Dodo do not retry for 36 hours typically, and do use different IPs, so you may not receive mail from them for many days, if at all. I think Dodo and any similar ISPs need to be on the whitelist. There is a default whitelist of known bad senders IP's installed by default from the rpm.

See
var/qmail/greylist
var/qmail/whitelist
Also see
/usr/local/bin/qgreylist - for setting details & explanations.

I suggest you try greylisting out so you can gauge the effectiveness & see if complaints about delays end up being realistic or "all in the mind".

Having said all of the above, there is no guarantee that the sme developers will continue using/supporting greylisting. It has its pros & cons, so gauge for yourself.

I should add my thanks to Gordon Rowell & Charlie Brady for their help in improving my understanding of greylisting.

Regards

[KelvinLee]

Hi Ray,

how do you or the end users know that the delay would be "totally unacceptable".

Because I know these people. I have been there when they were on the phone with the other party and e-mailing each other stuff while they were still on the phone with them, negotiating or closing deals or whatever. Any delay in the mails would be unacceptable to them. It's not my place to tell people that they should not be doing such things as I do it myself sometimes when troubleshooting problems with clients.

Whitelisting is not an ideal soultion as it is still considered too "hands on" for them. Additionally, if you whitelisted too large a block of addresses, you could end up letting through the very things you are trying to block anyway.

I'm sure you know that there is nothing immediate about email as it can be quite slow at times

That would of course depend on a number of factors. However, the quality of their service have always provided them with nearly instant mail all along (as have my own) and there is an expectation that the service should remain the same.

And yes, they do realise that if they sent an e-mail with a 5MB attachment, they are not likely to see it straight after hitting Send.

I tried it myself on my own server

As did I. I sent myself 4 consecutive e-mails from a Bigpond mail account. The first 3 bounced after a while and the fourth arrived almost straight away. Watching the greylist, I saw that the first 3 mails arrived via different mail servers and the 4th I assumed came in via one of the first 3. As I watched the greylist folder, I could see more and more IPs get registered. However, more than an hour later, I still did not receive ANY of those mails. Most of those IP addresses are from my clients. I can only assume that they have either bounced or delayed for retry later. However, this delay would definitely be unacceptable to those clients (as it is to me).

Greylisting remembers the sender IP and only the first message is delayed

This totally negates one of the main things I'm trying to accomplish. Eg. the recent Sober Worm outbreak. An infected PC could be sending hundreds of infected mails, most with faked, non-existent domains but all coming from the same source IP. Greylisting would only block the first one but then let all the others through. RBL does not work as the domains are non-existent and are just randomly generated letters. Dropping them if they were from non-existent domain would have cut down nearly all of those mails.

When you find out (probably by a complaint from the sender)

In industries where first contact counts heavily (like some of my clients), I would say that this is simply unacceptable. If a potential customer comes by my clients contact details (via an ad or referral or looked it up on whitepages, etc) and sent an enquiry in only to have it bounce, there is a very high probability that they won't try again resulting in loss of potential business.

Don't get me wrong. I'm sure greylisting works well in some situations, just not in these situations (or mine either).

Cheers,

Kelvin