Re: [exim] is this spam unable to track source

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Bill Hacker
Dátum:  
Címzett: exim-users
Tárgy: Re: [exim] is this spam unable to track source
Fred Viles wrote:

> On 24 Jan 2006 at 7:32, Bill Hacker wrote about
>     "Re: [exim] is this spam unable to t":

>
> |...
> | Short answer: in the HELO section, the earliest the '$sender_host_name'
> | could be determined.
>
> No, I don't think that's right. As I read TFM, $sender_host_name is
> the name derived from a PTR record lookup for the connecting IP
> address, so it can be referenced in the connect ACL as well.


Mea culpa. I should have gone into some extra detail as to my positioning:

You are technically correct, but that positioning is 'temporally
sub-optimal'.

Reason being that there is a finite lag of ca 300 ms - sometimes a lot
more -
while that information is sought and recovered remotely.

Rather than have that child process sit idle, I choose to allow the
connection
to proceed to other tests, some of which will reject the connection on
equally
'low cost' grounds (rude pipelining, HELO as me, etc.)

- all while that remote-query process in still 'airborne'.

Cuts Exim process time as well as potentially releasing a TCP connection
sooner.

The snippet furnished is also a part of a longish 'suite' that checks
for forgeries from a
whole raft of commonly-forged MX (yahoo, msn, hotmail, aol, att,
verizon, comcast...)

I don't even want Exim to bother entering that acl if a simpler test can
reject and/or
'jail' a connection that will voluntarily abandon 'real soon now'
without it.

That test may come later than it might, but can be one that uses fewer
total resources
an less time.

Many 'zombies' WILL step on their own anatomy early-on in an 'protocol
violation' manner
well before one needs to look further or do more time/resource-intensive
testing...

The result for a 'production' server hosting a dozen or so virtual
domains is;

- SA & ClamAV invocation for perhaps one arrival of 20

- rejection of 1,000+ wincrobe/spam per day

- an average FreeBSD 4.10 server load of under 1%

all on a 1.2 MHz Celeron with 1 GB of 133 MHz SDRAM and slowish
ATACONTROL RAID1.

Cheap rackmount box, and still loafing - even with 'costly' PostgreSQL
used for lookups. ;-)

>
> | Longer answer:
> |...
>


(research, learning, and enhanced logging)

> Excellent advice!
>
> - Fred
>

Thanks!

- Exim has extensive docs, but we DO need a simpler step-by-step intoduction
so as to not overlook the 'basics' of the SMTP handshake sequence where
many folk
go astray.

- Helpful if each variable specified the earliest/most appropriate
smtp-process step
to which it applied, and in the briefest listing manner.

- 'Extra' logging can provide rapid 'local' answers, not to mention
making it easier to
get accurate help if/as/when still necessary to post here.

I have a picture on the wall from my piloting days, of a biplane
crash-landed in the top
of a huge tree, unhurt pilot walking dejectedly toward the camera....

Caption:

"Flying is not inherently dangerous, but to an even greater extent than
the sea, it is terribly unforgiving of carelessness, incapacity, or
neglect"

Substitute" Configuring an MTA is not..."

..and that might be a good motto for Exim as well... ;-)

Best,

Bill