On 9/28/2016 7:04 PM, Alex wrote: > Hi, > > On Wed, Sep 28, 2016 at 5:46 PM, Noel Jones <[email protected]> wrote: >> On 9/28/2016 4:15 PM, Alex wrote: >> >>> How can I modify the lines in my header_checks.pcre file to provide >>> more info on the specific pattern that's causing the problem instead >>> of just "message content rejected" the next time the email is >>> received? >> >> Note the log entry may not be the complete unmodified header, so >> testing the log entry against your header_checks won't always work. >> >> Since your log entry doesn't show any custom message, you can narrow >> it down to rules that just have REJECT, which makes the >> mime_header_checks file the prime suspect. >> >> Instead of just REJECT, use a unique text identifier on each rule. eg: >> /.../ REJECT rule 1 >> /.../ REJECT rule 2 >> /.../ REJECT rule FC45A > > Okay, thanks. I'm doing this already on the pcre header_checks file, > and have added it on the mime_types file, but noticed a problem with > the pattern matching: > > /^Content-(Disposition|Type):\s+.+?(file)?name="?.+?\.com(\.\S{2,4})?(\?=)?"?(;|$)/ > REJECT ".com" file attachment types not allowed > > Sep 28 19:00:30 mail03 postfix/cleanup[31039]: 7B2BC209EDF9: reject: > header Content-Type: image/png;??name="Exterior Canopy > Light.png";??x-apple-part-url="[email protected]" > from nm32-vm0.bullet.mail.bf1.yahoo.com[72.30.239.136]; > from=<[email protected]> to=<[email protected]> proto=ESMTP > helo=<nm32-vm0.bullet.mail.bf1.yahoo.com>: 5.7.1 message content > rejected > > Why didn't it print the "file attachment types not allowed" and > instead the more generic message? Running postmap manually does print > that: > > # postmap -q 'Content-Type: image/png;??name="Exterior Canopy > Light.png";??x-apple-part-url="[email protected]"' > pcre:header_checks-jimsun.pcre > REJECT ".com" file attachment types not allowed > > I checked to see if it was perhaps hitting another rule, and I don't > see any that match "png" specifically. How can I adjust that rule to > only block files that actually end in '.com'? >
There may be another matching rule in mime_header_checks. See the sample expressions on the header_checks man page. -- Noel Jones
