Re: [exim] Image spam stopping...

Página Principal
Apagar esta mensagem
Responder a esta mensagem
Autor: W B Hacker
Data:  
Para: exim users
Assunto: Re: [exim] Image spam stopping...
Joseph wrote:
> W B Hacker wrote:
>> James Price wrote:
>>> I've noticed and read up to confirm, most image spam comes in with the
>>> following in the header. I have an ACL rule already in acl_smtp_mime as
>>> follows:
>>>
>>> deny    message = Image SPAM detected: message denied
>>>       condition = ${if eq{$mime_content_type}{multipart/related}{1}{0}}

>>>
>>>
>>> I'm looking for this:
>>> Content-Type: multipart/related;
>>>     type="multipart/alternative";

>>>
>>> If I wanted to expand my rule above to also require matching of the
>>> multipart/alternative, how would I do that since they're in the same string?
>>>
>>> If anyone has other more effective ideas to stop image spam, I'm open to
>>> suggestions. The rule above has caused some issues with false positives for
>>> me.
>>>
>>> Thanks,
>>> James
>>>
>>
>> But if you have a 'corporate' environment or other small user pools, as we do:
>>
>> In acl_smtp_recpt phase, deny some or all graphical (or other) attachments with
>> a message such as:
>>
>>     message     = \n Addressee accepts attachments, \
>>                   \n ONLY by prior arrangement! \
>>                   \n Send plaintext message first to arrange.

>>
>> - To make admin less painful, our 'to arrange' process is a simple directory
>> search of our policy-mandated archive tree for prior outbound FROM our local
>> addressee (the recipient) TO the now-arriving sender (envelope and/or From:).
>
> Could we see an example of how this can be done?


The above should be coupled with your choice of 'detection' parameters and
allowable/banned choices.

> The 'to arrange' part, how does the archive you refer to get created?
>


With 'unseen' routers, & appropriate transports, e.g:

(router)

# ROUTE_2D REMOTE: archiving of outbound traffic.
#
sentarchiver:
driver = dnslookup
domains = !+local_domains
transport = sent_archive_delivery
ignore_target_hosts = <whatever>
unseen

awl_archiver:
driver = dnslookup
domains = !+local_domains
transport = awl_archive_delivery
ignore_target_hosts = <whatever>


(transport)

# TRANSPORT_3C REMOTE delivery AWL builder
#
awl_archive_delivery:
driver = appendfile
user = exim
group = mail
delivery_date_add
envelope_to_add
return_path_add
maildir_format = true
mode = 0770
directory = /<someplace>/${domain}
create_directory = true
directory_mode = 0770
no_mode_fail_narrower

Note that this one only has per-domain granularity, not per-distant user (doable
if need be).

That would open AWL, to, for example, ALL of @gmail.com etc. - but we also
filter forgeries on incoming, AND have other special rules for such
spam-is-always-inherent senders as @yahoo.com's webmail, so it has been more
than good enough to reduce false positives and bitching and moaning in general.

Side issue, but the first archiver's transport stores in a different hierarchy,
relieving an IMAP user of the need to "copy to the 'Sent' folder" or Bcc:
themselves.

Exim does that for them before it even runs the remote DNS delivery attempt.

Downside is it may not have been accepted yet. Or even deliverable as addressed.
Had one with an IP where their MX record wants domain.tld just yesterday.

Upside is ease of re-transmisison on fail. Retry quits 'real soon' so biz users
know *NOW* that a possibly time-sensitive message needs a fax or phone call
fallback. 3-4 days of retry is no longer appropriate when *most* mail moves in
well under a minute.

As said - not for everyone... Adapt with care. And lots of logging and testing.

>> The effect is that most 'regular correspondents' are pre-approved before the
>> first attachment ever hits the rule, and spambots almost never are.
>>


*snip*

Bill