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.


-- 
## 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/

Reply via email to