Subject: Re: [Asrg] 0. General

From: Brad Knowles <[email-masked]>
Date: Mon, 27 Oct 2003 00:08:27 +0700

At 1:18 PM -0400 2003/10/23, David Maxwell wrote:

>>  	That's fine, but keep in mind that this has collateral damage
>>  	consequences.
>
>  It's my choice to accept those consequences - it's _my_ consent
>  decision.

	That's fine -- up until the time where you tell other people that 
they should be doing the same thing.

	If you want to insert lit explosive devices into your body, 
that's one thing.  But when you start encouraging other people to do 
the same, that's totally different.

>  That's not an abuse of DRIP. DRIP provides a layer upon which I can add
>  a white/grey/blacklist by domain. Without DRIP (or RMX, etc), I cannot
>  whitelist by domain, since spammers can forge spam claiming to be from
>  one of the domains I whitelist.

	They could do that anyway.  Remember the previous discussion of 
DNS cache poisoning?  Even if your servers are immune to cache 
poisoning, what are the odds that the advertised nameservers of all 
your whitelist domains are also secure?

>  Many of the viruses forge email source. If they didn't, I could easily
>  contact the sender and tell them to cleanup their machine.

	Just forge the username.  Unless you contact the system 
administrator at that ISP and get them to match the username against 
the IP address at that particular time, you'd never know (that's 
assuming they have accurate logs for that time, or that they're 
willing to do this for you since you're not a paying customer).  Or, 
forge the username within any of the other domains which are hosted 
by those machines.

	Of course, another issue with open caching/recursive servers is 
that you can get anyone in the world to effectively host your domain 
for you, and combined with wildcards they could appear to be hosts 
for virtually all domains on the Internet.

>  I'm not rejecting the mails in the SMTP phase - so the RFC specs are not
>  relevant - however, the fact that I cannot implement
>  white/grey/blacklists leaves content inspection as the only method to
>  identify spam. That 'guesswork' takes a lot of CPU time, and gives me a
>  very non-deterministic answer anyway.

	You're going to be forced to do that anyway.  You're just going 
to force the spammers to get that bit more crafty to by-pass your 
so-called protection mechanisms.

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Brad Knowles <[email-masked]>
Date: Thu, 23 Oct 2003 19:23:31 +0700

At 4:32 PM -0400 2003/10/22, Kee Hinckley wrote:

>  Then you enter into an interesting resource battle.  Who has more
>  resources that they can afford to keep around doing nothing?

	Yup.

>                                                                That's
>  a dangerous game to play.

	It can be.  You need to know when to stop trying to play this 
game, and to instead change the rules (i.e., change your router 
filters so that they can't even get in at all).

>                             But in any case, my mail server doesn't
>  support it.

	I'm sorry to hear that.  ;-(

---

From: Brad Knowles <[email-masked]>
Date: Thu, 23 Oct 2003 19:22:39 +0700

At 9:26 PM +0200 2003/10/22, Markus Stumpf wrote:

>  We have some busy mailservers running a connenction limit of 250 parallel
>  connections at all.

	Which is known to be a bad idea.

>  While I have noticed I have no problems with 50 connections in tarpit from
>  different hosts (some from the same) you can easily run in a homegrown
>  DoS if the number of concurrent tarpitted connections becomes too high.

	This is why.  Don't restrict yourself to a given number of 
simultaneous parallel connections, unless you understand the risks 
and are willing to live with the consequences.  This is laid out in 
the documentation for both sendmail and postfix, and presumably for 
other MTAs as well.

---

From: Brad Knowles <[email-masked]>
Date: Thu, 23 Oct 2003 19:23:18 +0700

At 4:07 PM -0400 2003/10/22, David Maxwell wrote:

>  So, connections from nameless IPs probably deserve to be weighted as
>  'spam-likely' in your consent decision. Perhaps even 'spam, guaranteed'.

	That's fine, but keep in mind that this has collateral damage consequences.

	Use DRIP (or DRIP-like techniques) as a whitelist, and that can 
be abused, too -- Plenty of spammers are perfectly happy to 
authenticate in whatever way you want, and will make sure that their 
reverse DNS fully matches, etc... just to get their mail through. 
Then there are the virus/spammers who use victim machines distributed 
around the world, most of whom probably are properly configured to 
use outbound mail relays that are likewise correctly configured.

>  That design decision was made before the current situation came into
>  being. Now, my spamassassin installation spends far more time doing
>  content inspection on spam messages than the 'too much time' it would
>  take to validate the provided hostname.

	Then your spamassassin configuration is not correctly configured. 
You shouldn't be using it that way unless you can make sure that you 
can conform to the same kinds of situations and response times as 
were anticipated when the RFC was written.

>  The network environment has changed, the assumptions about overhead need
>  to be re-evaluated.

	Re-writing the RFC is a different matter, something which I 
believe we are also participating in.  However, until the RFC is 
re-written and gotten to at least the "Proposed Standard" stage, you 
should not be knowingly in violation of it.