Re: [exim] Mime + filename matching

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Craig Jackson
Dátum:  
Címzett: exim-users
Tárgy: Re: [exim] Mime + filename matching


> -----Original Message-----
> From: exim-users-bounces@???
> [mailto:exim-users-bounces@exim.org] On Behalf Of Phil Pennock
> Sent: Friday, February 08, 2008 7:10 PM
> To: Craig Jackson
> Cc: exim-users@???
> Subject: Re: [exim] Mime + filename matching
>
> On 2008-02-08 at 16:39 -0600, Craig Jackson wrote:
> > Okay, I'm really showing my mime ignorance here, but it only happens
> > when the attachment shows up within the body of the email
> as if it were
> > inline rather than as an attachment (using Thunderbird). I hope that
> > makes sense. The size of the emails are well over the limit in every
> > case. I've tried duplicating this by sending the exact same
> attachment
> > but the acl catches it. It's got to be a mime issue. Here's
> the header
> > from an email containing the same image sent from a yahoo! (god help
> > them) account to me that was caught by the same acl:
>
> Okay; I diagnosed on most obvious issues, such as size, rather than
> looking deeply into the regexp. Having more data definitely helps.
>
> Which ACL is this on? You don't mention that.
>
> What do you see in debugging output when you bounce such a message
> through Exim? "exim -d+acl+expand" should be useful.
>
>      condition = ${if or { \
>          {

>
> match{${lc:$mime_filename}}{\N^(?>.*)(?<=zip|emz|iso|wma|jpg|j

peg|pps|ppt|gif|png|wmv|mpg|mp3> |mpeg|avi|wav|bmp|mov|asf|asx|mpe)\N}}
\
>          {

>
> match{${lc:$mime_content_type}}{\N^(zip|emz|iso|wma|jpg|jpeg|p

ps|ppt|gif|png|wmv|mpg|mp3|mpeg|avi|wav|bmp|mov|asf|asx|mpe)\N}} > \
>          }{1}{0}}

>
> The second regexp is matching a filename extension pattern against a
> content-type. Something like image/bmp is a content-type. What you
> have will work, accidentally, where the mime sub-type name matches the
> extension.
>
> In the first case, checking against mime_filename, you use atomic
> grouping to match on the entire filename (?>.*) and then
> check that what
> comes just before has the relevant letters; you're not
> actually checking
> that it's an extension, so a file named "bmp" would match, as would
> "foo.xbmp". So it's buggy, even though it should catch the case you
> have.
>
>
>
> Also, why is it that none of my replies to you get delivered to you?
> You seem to hang at RCPT stage until the sender (my system) times out.
> Every single time I reply to you. Every delivery attempt. Whatever
> response you see is coming in via the list. The bounces are ...
> irritating.
>
> 2008-02-08 22:32:32
>   cjackson@??? <CJackson@???>
>   R=outbound_signed T=remote_dksign
>   defer (60): Operation timed out:
>    SMTP timeout while connected to puma.abbott-simses.com 
> [64.66.85.242]
>    after RCPT TO:<CJackson@???>

>
> -Phil
>


Phil,

First, I apologize to you and the list for the bounces. Our blacklist is
quite aggressive as the owners of the business will not tolerate any
spam. I am constantly tinkering with the Exim acls to avoid using
Spamassassin which doesn't really work well. So I started checking where
the spam is actually coming from (IP address) and found that 90% is
senseless garbage from Asia, Latin America, Europe, and Africa. Not
realizing that those networks were broken into subnetworks (ARIN doesn't
give that information), using Exim acls, email from those entire
networks, plus a long list of networks in the US and Canada, are made to
wait too long - 600s. Almost all spam disconnects during that time. 95%
of my spam is gone. Now, I have found the RIPE site, so rather than
"waitlisting" entire overseas networks, I intend to break them up, only
waitlisting offensive networks. I'll start with the European networks.
In the meantime, I need to set reply-to: as the list so you do not get
bounces. Again I am sorry for this temporary irritant.

Second, the problem with this mime acl: I understand something more
since I went back and reread the spec.txt. The mime_filename is derived
from the content_type or content_disposition headers - but no other. Not
all MUAs set the filename in these headers. In the above case,
mime_filename was set in the content_id header, thus Exim set
mime_filename to the empty string. So why didn't Exim set the second
part of OR condition (that is the content_type check) to true and thus
the entire condition to true. I used exim -d+acl+expand -bh IPADDRESS to
see all this. The answer must be that I made a mistake in there
somewhere. So am rechecking and will get back to you. Thanks for your
patience.

Craig