Re: [exim] Changing Email Identity

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: W B Hacker
Dátum:  
Címzett: exim users
Tárgy: Re: [exim] Changing Email Identity
gascione wrote:

> Perhaps a little clean history is in order.
>
> We have 6 pretty decent Debian Linux machines handling inbound mail as mx
> servers. All MX records are set to the same preference so we load balance
> pretty well.
>
> Each server does the prelim stuff, HELO checking, valid envelope, stuff like
> that and there are some deny's from these fatal things.
> We also do some dictionary attack stuff in Exim but we also run IPtable
> rules to kill the real DOS stuff.
> Off to ClamAv to get accepted or dropped like a rock
> Next we go into sender/recipient verification which dumps a lot of crap as
> well.
> Then we go into DNSBL which only tags headers.
> Then on to a few other ACL's and then off to Spamassassin/Razor for scoring
> Then it's finally sent on to the primary mail cluster which is a cluster of
> Windows based mail servers doing both secure and unsecure POP, SMTP, IMAP,
> and also Authenticated SMTP for outbound.
>
> Outbound: Another 6 Exim servers load balanced
> Outbound mail checked again almost with the same intensity as inbound mail
> before sent out. No spamassassin on the outbound side.
>
> We serve over 11,000 domains and somewhere in the order of 300k email
> accounts. We simply cannot drop mail unless it's obvious that there is a
> problem. We do not have the ability to stop mail from coming in to our
> network because its from Korea or someplace. Many of our hosted customers
> are international.


Well *all* of ours are. Even 'house' accounts, such as retired Chairmen of
various major firms that are on, or advisors to, our own BOD.

I am as likely to be admin'ing from the US or Europe as Hong Kong or somewhere
else in Asia.

> Not even for reverse DNS can we dump mail. Do you have
> any idea how many idiots are running in house exchange servers and have no
> clue what they are doing.


Sure do. ~/exim/rejectlog is full of 'em.

We'll even whitelist 'em if they are Fortune 400 firms.

NetWork Solutions St. Louis 'pool' of outbound cheap-hosting-parkers mx, to name
one.

> so reverse dns is not an option for dumping mail.
>


By itslef, no. But *way* before you hit SA, it can be combined with some other
tests that can safely ID and allow dropping the 'zombies'.

Ex: some bit of mal-code out there has been trying harvested legit addresses
here for many years. USes IP's and such all over the known universe.

Downfall is that it always mixes in either 'milakikuta@<our domain>.<tld>
one 'anastasio@<our domain>.<tld>'. We don't drop the message. We drop the
connection, as we have never had any such users on any of our domains.

> So all this crap finally hits the primary mail cluster and there it is very
> well scored and marked up in the header with all kinds of tags. We even have
> custom ACL's for spamassassin to rate the score so people can filter on it.
>


Likewise. Per-user-account settings for the level at which it:

- gets even a header

- gets an altered 'Subject:' line (Lusers don't often display headers..)

- goes to quarantine

- is blackholed

> The filtering works fine but, and here is the main cluster Fu..., our mail
> servers don't look beyond the first "from" when they compare inbound mail
> against the user's white lists. So any false positives must be handled with
> a content filter rather than just the simple white list provided by the mail
> server software.


Umm.. our user whitelists have more to do with the (alleged) server identity
(IP and/or hostname) and HELO (sometimes forged, but repetitiously so) than the
specific user sending.

That, of course, must either be handled in real-time during the smtp connection
(SQL DB has the settings for all servers).

OR - one needs to use what info is available, and concatenate it into a
'special' header.

That, I suspect, is where your mention of needing to code on MS WinWoes came in.

But w/r Luser whitelisting - are you looking at the 'From:' header? or the
'envelope'?

AFAIK, exim doesn't (or does not NEED to) alter both of those..

>
> Yes, I know it's a problem with the mail systems but there is no options
> with them right now. If I can just get rid of the damn first "From" header
> in the email or move it down life would be a scotch on the rocks next to the
> pool.
>


ISTR it was the 'Received: header you were dealing with? Not from.

Moving it, or 'faking' a move by sticking one in ahead of it should do that.

>
>
> Want to know more?


Not really.

'Coz here is one for you....

I just looked - for the first time - at the headers of your post to the list.

'*nabble.com' has been in our REGEXP-block list for so long I don't even have
logs still handy that would explain *why*. (Doesn't affect sesame..)

So all those servers, and all that work, may not have prevented enough of your
user-community getting infected or not blocked the infestation from getting back
out. Bigtime-zombie - at least a burst of same, I would suspect.

I'm opening it up just now. There is an SQL gadget oerational that builds new
LBL candidates, so will see when/if a problem resurfaces.

Best,

Bill












>