Re: Networking -- use of two Internet connections for one server with round robin DNS -- web okay, but should I do mail this way too?

[lee <lee@yun.yagibdah.de>]

Stan Hoeppner <stan@hardwarefreak.com> writes:

> On 7/10/2011 8:31 PM, lee wrote:
>> Stan Hoeppner <stan@hardwarefreak.com> writes:
>> 
>>> On 7/10/2011 7:26 AM, lee wrote:
>>>> Stan Hoeppner <stan@hardwarefreak.com> writes:
>>>>
>>>>> On 7/9/2011 12:00 PM, lee wrote:
>> Yes, the HELO checks are first.  It seems to make sense that way.
>
> Most MTAs lookup the hostname long before receiving EHLO.  One can
> reject mail sooner if configured to not wait for SMTP logging info
> (HELO, MAIL FROM, etc).  If you wait it doesn't really matter as you
> have no speed gain.

when it doesn't involve DNS lookups anyway, it might make sense to run
the rDNS check earlier than the other HELO checks.  Trying it out and
examining the logfile would tell.

> This 'trick' would only be applicable to extremely
> high volume MX hosts, i.e. > 300 connects/second.  Such systems likely
> have upstream firewalls killing most of this traffic beforehand though.
>  Lots of different ways to kill spam.

Yeah, when you know in advance from which IPs you don't want to receive
mail, you can lock them out before they can contact the MTA.  Isn't that
something that could be done with your table?

>> What do you consider low mail flow?
>
> Personally?  Generally less than 50,000 connects/day.  If you ask an
> admin at one of the universities with 30k+ students, he'd probably tell
> you anything less than 500k connects/day is low mail flow.  This answer
> depends on who you ask.

That's why I ask :)  I haven't had the pleasure yet to run a mail server
that got anywhere close to 50k connects.

>>>>> http://www.hardwarefreak.com/fqrdns.pcre
>>>
>>> I take it you are you really new to managing a mail server.  dnsbls have
>>> been around forever, and every mail OP uses one or another, if not 5 or
>>> more.
>> 
>> That they are around for a long time doesn't mean that I have to like
>> them or to have others decide what mail to accept or not to accept.
>
> That they have been around a long time, and have a solid reputation for
> blocking spam and not ham, is the key.  I don't know why you wouldn't
> 'like' them.  I think you simply need more exposure to spam fighting and
> the excellent free tools available to you.

Spamhouse blocks you even when you haven't done anything wrong and then
refuses to remove you.  I guess others aren't any better.

And as I said, I don't want others to decide about what mail I can
receive and what not.  How would you like it if the postman supposed to
deliver your snail mail would decide by his very own rules which of the
mail addressed to you he delivers?  Email is the same, I don't want you
or anyone else decide what mail I can receive and what not.

>>> Have you heard of SpamAssassin?  Both restrictions make
>>> reject/keep decisions for you.  Using this PCRE table is no different in
>>> that regard.
>> 
>> Spamassassin seems to be doing a good job; I don't know about your
>> table.  Both ways of filtering make decisions for me --- that's the
>> idea.
>
> The same is true of configuring EXIM/Postfix/etc to reject based on lack
> of PTR, incorrect HELO, etc.  It's called automation.  You already allow
> your MTA to make block/accept decisions for you.  Using external or
> other tools is no different in this regard.

It is much different.  The difference is that it is my decision how to
use these tools and how to configure them.  When I decide to use a
blacklist like Spamhouse has, others decide who's blacklisted and who's
not, and that's a decision I have no saying in.  I can either use their
list or not and don't have any control over the list itself --- but I do
have control over how I configure spamasassin.

>> Since when can anyone take a given delivery time of emails for granted?
>> I can see people being stupid enough to do that, though.  The delay with
>> graylisting remains a disadvantage.
>
> For most SMTP mail systems that are properly configured, successful
> delivery occurs within a few seconds to a couple of minutes, depending
> on source and destination geographic location and the current load on
> each system.  The misconfigured systems, including those with a poor
> greylisting implementation or other poorly implemented anti-spam
> countermeasures, are the ones that inject significant delay.

So nobody can take delivery times for granted.

> we have 50% of all in/outbound messages delivered in less than 2.5
> seconds and all messages delivered in 14 seconds or less.  This is a
> well configured MTA.  Keep in mind it does have significant anti-spam
> features, most of them custom.  It does not make use of a content filter
> such as SpamAssassin, or any policy daemons, however, which helps keep
> delays relatively low.  It does use a custom header_checks TCP server
> which does add a second or so of additional delay as it queries 3 RHSBL
> servers.  And this is on 11 year old hardware.

That doesn't say much without knowing how much mail is running
through.  It's nice that you don't need graylisting and Spamassassin
since graylisting introduces delays and Spamasassin can be troublesome
on resources.

>>> The fqrdns.pcre table gives most of the "catch" performance of
>>> greylisting without the downsides.
>> 
>> I can see why you like it.  How do you make sure that mail you want to
>> receive isn't rejected when using the table?
>
> Because no one should be receiving email directly from residential PCs,
> most which have dynamic IP addresses, some static addresses.  They
> should never be sending email directly to MX hosts.

Well, I see that very differently.  BTW, is there an RFC yet that makes
having a static IP a requirement for sending mail?

> Only bot infected PCs do that.  This table targets residential type
> rDNS strings, which identify the PC as being residential, or less
> commonly, SOHO.  In either case, they should be relaying email through
> their ISP's mail relay, which we state in the reject messages in the
> table.

That's a decision you made, and it's an example for a case in which the
decision of what mail I want to (or, rather, can) receive would be made
by someone else.


-- 
html messages are obsolete