On Monday 16 May 2005 01:57, Ariel Sabiguero Yawelak wrote:
Q: Can I delete SPAM and reject NON-SPAM misspelled mail addresses ?
As spammers are getting more and more intelligent, differentiating spam and legitimate e-mail becomes more difficult, too. Technically, you may be able to do this in the future (given software patents are abolished and popular frameworks for countering spam actually become free) using SPF (Sender Policy Framework), which, simply put, registers all sending MTAs for a given domain in that domain's DNS records, so you can trivially check if you're getting the message from a MTA that actually is authorized to send e-mail with return path from that domain. However, right now, there is a shadow of doubt over whether this will ever become a real standard that everyone will follow (of course, that would be beautiful).
The problem I have found is that bussines people don't want their customers to miss them! I believe that many of you need to handle virtuals like
jd jdoe johndoe john_doe john.doe doej doejohn doe_john
all pointing to the same account, but they also want rejects to be sent to the sender so they know that the mail didn't reach the intended recipient... all of which is true and valid without spam. Is it possible to handle both things smoothly?
One of the best technologies for fighting spam on large e-mail systems or on systems with catch-all mailboxes (that receive all mail destined to a specific domain that didn't match valid addresses) I have seen to date is greylisting. The idea is quite simple: you temporarily reject *all* e-mail from every SMTP client you haven't spoken to in a while (excluding the obvious ones, e.g. your own networks and secondary SMTP servers and such) with an error code of 4xx, which means the sending MTA will try to deliver the message again within a few minutes. This puts some burden on the sending party's resources, because they have to requeue the e-mail and send it again at a later time, and most spammers don't want to do this. They definitely will, eventually, but today, this still works very well. This also means some legitimate e-mail will be a few minutes late, but that isn't as bad as your machine having to eat through thousands of spams every hour just to drop them on the floor, or even some of these getting through to your customer's inbox. For a specific greylisting implementation for your MTA, try google. Another possibility is postfix's policy daemon and sender address verification, which are usually very costly (and therefore only applicable to smaller e-mail systems). These two enable postfix not to bounce e-mail, but reject it outright (so your system will very seldom have to generate a bounce to a spam), but of course this means eating up a lot of resources, because you have to be able to check whether an e-mail is legitimate or not, rather quickly. Furthermore, sender address verification may not work for all MTAs out there, so some legitimate mail may be unjustly rejected (however, this still sticks to the RFCs because it does generate an error on the sending MTA, instead of silently throwing it away, which is what most big systems are forced to do because of the magnitude of spam e-mails they receive). -- Jure Koren, n.i.