Re: [exim] we all agree, let's drop that spam

Page principale
Supprimer ce message
Répondre à ce message
Auteur: W B Hacker
Date:  
À: exim users
Sujet: Re: [exim] we all agree, let's drop that spam
Rick Duval wrote:
> First, that's a lot of info, thanks for taking the time to give such a
> detailed answer.....


Well .. a bit MORE reading and you would have found all that .. and more.

>
> It's not so much a matter of wanting to reject some of the additional
> recipients "at the front door" (which would be nice of course), it's
> more of wanting to run separate copies through MailScanner (which has
> a custom app we've written which accepts or discards emails based on
> the individual users preferences).
>
> Effectively I'm just looking for someway for exim to copy the emails
> and re-address the "to:" header and put a separate copy for each name
> in the queue (which is all Exim is doing in my system, MailScanner
> picks them up from the queue and does it's thing).
>


No need.

You'e missed the OTHER point.

Exim *has to* take in just one message per many recipients, 'coz that's
all it is offered.

But once past the smtp active connection and into the router/transports,
each 'local' message IS delivered to one recipient at a time.

Exim can make a delivery based on same-SA score (previously run OR run
NOW), but by different user-pref as personalized response to that score.

OR it can route the traffic to a filter or third-party scanner.

Or both. And more.


But I should advise you of another too-often overlooked item.

The NTA-world is chock full of folks who 'play with' spam, eg scan and
'rate' gadzillions of messages, then brag about their message-count and
scores.

That's nonsense. Akin to swimming in the sewer, then bragging that you
have a good immune system.

No need.

IF one enforces the *basic* (as of 20 years ago) smtp RFC, not even
newer 'features' such as SPF and the like, *most* of that traffic will
not need scanning because you won't accept it at all.

CAVEAT: You will need systemwide 'whitelist' and per-user 'VIP lists'
because some players who should know better do NOT set up their MTA
properly... Harvard U. St Andrews Golf Club. Network Solutions....

but otherwise:

(NB some of these terms overlap and/or are actually duplicates):

- set Exim to NOT advertise pipelining, drop those who ignore that and
try it in violation.

- deny on local BL of unwanted IP (and/or put them into your firewall
ruleset). [1]

- deny on failure of forward/reverse DNS lookup / lack of PTR RR

- deny on lack of fixed IP and/or presence in dynamic-IP RBL

- deny on RBL hit of any of the top 3 or 4 RBL's.

- deny if HELO not in order, or on other protocol faux pas.

- deny on HELO mismatch to FQDN or at least obvious forgery

- deny on 'some' header format violations ('ALL' if you want to block
mail from Windows Outlook users..)

- deny on CLAMAV hit (a much lighter test to run than SA), and it does
not 'false'.

- deny on a local BL of unwanted REGEXP used in HELO or as domain.tld [2]

+++++++

At this point, you will have knocked out essentially all zombots, hence
MOST of the spam you were going to scan.

A slimmed-down SA, doing NO Bayesian, and content-scanning only (not RBL
checks or such - already done), can be run DURING smtp session.

- give your own 'outbound' a free pass on scanning. (We allow free for
OS/2, Unix, Mac, but scan Linux and Microsoft).

- give locally 'greenlisted' [3] traffic a free pass on scanning,

... and you will need to content-scan something like 2% to 10% of all
incoming traffic *offered*.

Result?

A server than delivers legitimate traffic in typically 1 or 2 seconds,
sits at 1% load most of the day, yet has broad enough shoulders to keep
on working when targeted with a DoS attempt that saturates the
front-side NIC.

Best,

Bill


Notes:

[1] /var/mail/IP-block is built 'by hand' becomes quite effective at
killing-off chronic entire botnets at around the one-year mark.

[2] /var/mail/REGEXP-block is also built 'by hand'. ditto.

[3] as we archive traffic, we do a directory scan to see if the incoming
presented for "recipient A" is from an address that "recipient A" has
previously SENT to. Same effect as 'if .. is in your address book..' w/o
need of access to the MUA address book.

>
>
> On Fri, Nov 21, 2008 at 9:51 AM, W B Hacker <wbh@???> wrote:
>> Rick Duval wrote:
>>> When you say you cycled through, did you split the mmulti-recipient
>>> message into separate messages?
>> No.
>>
>> You cannot do that *during* a conventional smtp process.
>>
>> In effect:
>>
>> The recipients are 'proposed' by the sender.
>>
>> The receiver indicates accept / reject.
>>
>> Both build a 'list' of each.
>>
>> *IF THEN* there is at least ONE recipient left, the message is handed
>> over. There is only ONE message.
>>
>> Sender tells those rejected.
>>
>> Receiver puts ONE message copy into its queue, separately (usually)
>> stores the delivery list.
>>
>> Each recipeint on the list is handed a copy of the message.
>>
>> Once the last one has been satisfied, the 'master' copy AND the list are
>> deleted.
>>
>> > If so, can you tell me how you did
>>> that. I'm implementing a similar system and want to treat each
>>> recipients email seperately, each with their own filter values. I'm
>>> trying to find an easy way to split the message into separates and
>>> then queue them for MailScanner.
>> As above - you cannot do that within the present-day smtp 'standard'
>> because once you have agreed to accept the message (DATA phase) it is no
>> longer possible to tell the sender 'in real time' that you are now
>> changing your mind and rejecting for one or more recipients.
>>
>> EXCEPTIONS:
>>
>> - Postive: Both sender and receiver are running courier-mta, which DOES
>> have such a feature the past ten years.
>>
>> - Not-so-good: Sender is running QMail, which splits the message into
>> one-at-a-time before sending, then sends 'many' in parallel. Looks like
>> a zombot, though.
>>
>>> I'm currently doing this but only the first is evaluated, so all of
>>> the recipients can have that piece of mail accepted or rejected based
>>> on the first recipients filtering choices.
>>>
>> What works NOW is to:
>>
>> - set a reasonable max threshold, accept below that, then 'quarentine'
>> by delivering for those with tougher standards into a bespoke folder
>> (IMAP recommended). Let the user decide how often they bother to look
>> into that folder. There can be more than one level of 'severity'.
>>
>> - ELSE limit all incoming to ONE recipient at a time.
>>
>> But that breaks compatibility with the standard, as one *should* accept
>> (at least) 100 per each go.
>>
>> If you have mostly one-recipient at a time *anyway* (as we do) no one
>> will notice.
>>
>> If, OTOH, you handle say five to ten - or several hundred - who have
>> been copied, taking them aboard one-at-a time means the last person
>> might see the same message minutes, hours - even a day later than the
>> first recipient. OR NOT (get it at all...).
>>
>> That doesn't fly well when they are in the same office.
>>
>> ;-)
>>
>> What you want to do is not new.
>>
>> It has been done for years with post-smtp milters, where the mail is
>> accepted by the MTA, THEN LATER a filtering/scannig/'tasting' engine
>> reviews it and optionally composes and sends a DSN rejecting soem messages.
>>
>> Doing that runs a risk of backscatter spam abuse.
>>
>> AND is a bit of a lie - in that the message WAS accepted on-box, (a 250
>> OK sent) MAY have been retained, yet is LATER said to have been rejected.
>>
>> Finally - there is another tool in the arsenal.
>>
>> IF you can place your users into, for example, four separate
>> <domain>.<tld> THEN you can take advantage of the fact that incoming
>> will be grouped by <domain>.<tld>, and place the users into groups with
>> similar spam thresholds.
>>
>> HTH,
>>
>> Bill
>>
>>
>> --
>> ## List details at http://lists.exim.org/mailman/listinfo/exim-users
>> ## Exim details at http://www.exim.org/
>> ## Please use the Wiki with this list - http://wiki.exim.org/
>>
>> --
>> This message has been scanned for
>> viruses and dangerous content by
>> Accurate Anti-Spam Technologies
>> and is believed to be clean.
>>
>>
>