Re: [exim] Image spam stopping...

Top Page
Delete this message
Reply to this message
Author: W B Hacker
Date:  
To: exim users
Subject: Re: [exim] Image spam stopping...
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
>


This is probably *totally* useless to even a smallish ISP, so no need to flame...

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:).

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

The rare exception not even necessarily including the gullible who think the
'..to remove.. link is for-real, as that is not ordinarily going to generate a
message to the alleged-sender even if/as/when clicked.

JFWIW... YMMV

Bill