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 'to arrange' part, how does the archive you refer to get created?
>
> 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
>
regards, Joseph
