[Mimedefang] Testing for port #/TLS in filter_relay

Philip Prindeville philipp_subx at redfish-solutions.com
Mon Mar 3 22:18:03 EST 2008


David F. Skoll wrote:
>
>> If I have to wait until I see the MAIL FROM, then that's a connection 
>> that is held open potentially for as long as my read-timeout is 
>> (currently 15 minutes), and someone could DoS attack me by sending me 
>> a bunch of connections but never advancing the state on them.
>
> Question: Is this a problem in practice?

Yes. See below.


>
> Question 2: If you dropped your read timeout to 60 seconds, would you
> ever lose legitimate mail?

Occasionally.  If we're doing an off-site backup, for instance (which we 
do periodically), our T1's get congested...

>
>> If, on the other hand, I drop the connection as soon as it arrives, 
>> then the window by which they could deny other clients from 
>> delivering mail is severely restricted to the RTT's of the attacker's 
>> connection times 3 or four.  Clearly, that's better than 15 minutes.
>
> The attacker merely has to DoS you from an IP address that's not on your
> blacklist (or, going back to your original policy of rejecting machines
> without reverse DNS, from a machine that does have a PTR record.)
>
> Regards,
>
> David.

That's not how sendmail blacklisting works.

It keeps track of the rate of arrival of connections from individual 
hosts, as well as a global cap.

I can say, "don't let any particular machine have more than 12 
connections arrive in a 60 second window", for instance.

And don't have more than 10 simultaneous connections.

But to answer your question, yes, it is occasionally an issue.

Especially with mailing list servers that don't batch deliveries and 
reuse a connection, but rather send flurries of messages... it's also an 
issue (for the reasons I just stated in my last message) with machines 
that hit me with a volley of simultaneous connections.

A lot of spamware doesn't try to cache or reuse connections, but rather 
will open up one connection per-recipient.

-Philip




More information about the MIMEDefang mailing list