The documentation for header_checks includes an example to "block
attachments with bad file name extensions", and I expect many
installations have a similar rule to cut down on malware. This reads:
/^Content-(Disposition|Type).*name\s*=\s*"?(.*(\.|=2E)(
ade|adp|asp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|
hlp|ht[at]|
inf|ins|isp|jse?|lnk|md[betw]|ms[cipt]|nws|
\{[[:xdigit:]]{8}(?:-[[:xdigit:]]{4}){3}-[[:xdigit:]]{12}\}|
ops|pcd|pif|prf|reg|sc[frt]|sh[bsm]|swf|
vb[esx]?|vxd|ws[cfh]))(\?=)?"?\s*(;|$)/x
REJECT Attachment name "$2" may not end with ".$4"
Unfortunately, this can now block valid email from iPhone/iOS/ithing
users. The second ".*" can span multiple parameters. This shows up in
logs when searching for "x-apple-part-url" as follows:
postfix/cleanup[1234]: 123412341234: reject: header Content-Type:
application/vnd.ms-publisher;??name="redacted
redacted.pub";??x-apple-part-url="abcd1234-1234-5678-9999-123412341...@yahoo.com"
What Apple has done seems legal under RFC 2045 but may make some of
their users' email undeliverable.
Rules can be amended to limit to "token" or "quoted-string" versions of
the filename like this:
/^Content-(Disposition|Type).*name\s*=\s*
("(?:[^"]|\\")*|[^();:,\/<>\@\"?=<>\[\]\ ]*)
((?:\.|=2E)(
ade|adp|asp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|
hlp|ht[at]|
inf|ins|isp|jse?|lnk|md[betw]|ms[cipt]|nws|
\{[[:xdigit:]]{8}(?:-[[:xdigit:]]{4}){3}-[[:xdigit:]]{12}\}|
ops|pcd|pif|prf|reg|sc[frt]|sh[bsm]|swf|
vb[esx]?|vxd|ws[cfh])(\?=)?"?)\s*(;|$)/x
REJECT Attachment name $2$3 may not end with ".$4"
A separate security point is that this doesn't actually block "bad"
extensions if the Content-Type name is base64 encoded and the filename
parameter in the Content-Disposition is percent-encoded.
Hope this is useful to some.
CK
