Re: [exim] Changing Email Identity

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



W B Hacker wrote:
>
> 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
>
>
>
>
>
>
>
>
>
>
>
>
>>
>
>
> --
> ## List details at http://www.exim.org/mailman/listinfo/exim-users
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
>
>


I'm either getting too tired or starting to feel the effects of the scotch
to understand your last couple of paragraphs. A problem I should know about?

--
View this message in context: http://www.nabble.com/Changing-Email-Identity-tf2425071.html#a6766428
Sent from the Exim Users mailing list archive at Nabble.com.