Hi,
I now have these mime_header_checks working properly, but it turns out
there are companies sending legitimate invoices as HTML attachments,
ugh.
Mar 8 07:49:05 xavier postfix-118/cleanup[2084042]: C01C310024593:
reject: header Content-Disposition: attachment;?
filename=purchase_order.html from
a31-88.smtp-out.amazonses.com[54.240.31.88];
from=<0100017f6993716e-42efe44-02df-4144-a0cb-35f9b82890b7-000...@mail.coupahost.com>
to= proto=ESMTP
helo=: 5.7.1 ".html" file attachment
types not allowed
Can I use sender_checks to bypass a host like mail.coupahost.com? The
client IP will constantly change, but I can rely on the sending domain
to remain the same.
If so, how do I control the ordering to be sure the mime_header_checks
are processed after the sender_checks?
On Fri, Mar 4, 2022 at 5:15 PM Alex wrote:
>
> Hi,
>
> > > I believe there's a dot missing in the first one, as in '.(386' but
> > > it's more than that, because I experimented with that too.
> >
> > No, it would have to be: \.(386|...)
> > otherwise '.' just matches any character. Your RE pattern is sloppy
> > in places, ... correct REs take some care.
>
> Yes, that is what I meant. I believe there were problems with the
> regex that I fixed, but I was also using header_checks instead of
> mime_header_checks.
>
> Just for completeness, here's what worked for me.
>
> Given the following attachment:
> --caef4405d964f4b8
> Content-Type: text/html; charset="US-ASCII"; name="download.html"
> Content-Disposition: attachment; filename="download.html"
> Content-Transfer-Encoding: base64
> Content-ID:
> X-Attachment-Id: f_l0chj96g0
>
> TWFpbGd1biBNYWduaWZpY2VudCBBUEk=
> --caef4405d964f4b8--
>
> $ postmap -c /etc/postfix -q 'Content-Disposition: attachment;
> filename="download.html"' pcre:/etc/postfix/mime_header_checks.pcre
> REJECT ".html" file attachment types not allowed
>
> mime_header_checks = pcre:/etc/postfix/mime_header_checks.pcre
>
> /^Content-(Disposition|Type):\s+.+?(file)?name="?.+?\.(386|exe|ad[ept]|app|as[dpx]|ba[st]|bin|btm|cab|cb[lt]|cgi|chm|cil|cla(ss)?|cmd|cp[el]|crt|cs[chs]|cvp|dll|dot|drv|em(ai)?l|ex[_e]|fon|fxp|hlp|ht[ar]|in[fips]|html|isp|jar|jse?|keyreg|ksh|lib|lnk|md[abetw]|mht(m|ml)?|mp3|ms[ciopt]|nte|nws|obj|ocx|ops|ov.|pcd|pgm|pif|p[lm]|pot|pps|prg|reg|sc[rt]|sh[bs]?|slb|smm|sw[ft]|sys|url|vb[esx]?|vir|vmx|vxd|wm[dsz]|ws[cfh]|xlw|xms|\{[\da-f]{8}(?:-[\da-f]{4}){3}-[\da-f]{12}\})\b/
> REJECT ".$3" file attachment types not allowed
>
> Can I also ask a more general question? How are other people handling
> attachments such as those I've listed which really have no purpose
> these days but to spread malware?
>
> The vast majority of HTML attachments we receive are not malicious,
> but just silently quarantining them was leading to too many support
> requests.
>
> Thanks so much for your help.
