Nix wrote:
On 1 Nov 2006, Andreas Pettersson stated:

Steven Dickenson wrote:
I can't agree with this.  Many small businesses in the US get just  these kind 
of static connections from broadband ISPs.
Comcast, for  example, has all of their static customers using rDNS that would 
fail  your tests, and they refuse to set up a
custom PTR record or delegate  the record to someone else.
I disagree on your disagreement. This is my opinion: If you don't have control 
over your rDNS, do NOT run any mail server, unless
you relay all outbound mail through a server at your ISP.

What if you don't *have* a server at your ISP that you can relay your
mail through, because your ISP expects you to send mail directly from
your own mailserver?

What if your ISP provides a server but it is horrifically unreliable?

In those two cases: Go to a service that hosts web/email servers under your custom domain, and relay through your own hosted server. They exist. Some of them aren't expensive at all.


Most of these static customers are legitimate business networks
running their own mail server, and have neither the need nor desire
to relay their mail through Comcast's SMTP servers.  I think your
general idea is very good, but you're reaching a little too far with
this one.
'No need nor desire', that's not really any good excuse. Use a relay
or find your mail rejected, I'd say.

Charming. They're not spammers, but you want to punish them as if they
were, because reality makes your tests too complicated.

Punishing them would be blocking them outright. Quarantining them is merely recognizing that they haven't obtained a class of service that would indicate a well configured and well maintained email server, as opposed to a fly-by-night or rinky-dink operation running on a bottom-feeder ISP's network ... characteristics that would indicate that the ISP is careless and not diligent, or that their customers have no care nor concern about their quality of service, either one making it more likely that I am dealing with a spambot or an open-relay. So, I make them jump through an extra hoop in order to get through to me. That extra hoop is either a) going through my quarantine process, or b) paying for a hosted service with proper RDNS. Either "don't look like part of a botnet" or "accept being in my quarantine all of the time".

It is not my obligation to accept nor view every email that hits my server. It is my prerogative to establish whatever hurdles I want to in getting through to my email inbox. It's not punishment, as punishment implies that I am removing your rights or privileges ... which doesn't apply, because you have no rights nor privileges with regard to my inbox. And, the fact is, the people you're trying to raise as a counter-case, are not only such a minority that they aren't on my radar, they're such a minority that they don't exist at all in my 15 months of experience in doing these checks.

Every sender which has connected to my machines, without being on my own subnet, nor performing SMTP-AUTH, and without passing these checks, has been sending spam or a virus. Without exception.


I realize that not everyone else is going to have the same experience with their email traffic that I do, which is why I'm making the plugin ever more flexible. First, I set a preference for just skipping some tests. Then, last night, I removed the hard-coded dynhostname and clienthostname checks. Now there's a "keyword" check, with the keywords used being supplied in the cf file. So, each site can set their own keyword requirement ... or leave it blank and skip that check entirely. (I haven't released this new code yet)


Reply via email to