Re: postscreen deep protocol tests and Amazon timeouts
On 15 Sep 2014, at 14:31 , Andrew J. Schorr wrote: > I could be wrong, but if greylisting works reliably, And there we get to the root of the problem. It does not work reliably because it ignores how large companies like Google and Yahoo and Amazon send mail. Greylisting, *BY DESIGN* screws up large company email. The entire basis of greylisting is that a single mail server sends email, and that is just not how email works for large senders. -- BILL: I can't get behind the Gods, who are more vengeful, angry, an dangerous if you don't believe in them! HENRY: Why can't all these God just get along? I mean, they're omnipotent and omnipresent, what's the problem?
Re: Enhanced Status Codes with Postfix policy delegation protocol
Viktor Dukhovni: > action=REJECT 554 5.7.23 Bleeding edge status code your MUA won't understand! action=554 5.7.23 Bleeding edge status code your MUA won't understand! REJECT is like 5XX, and DEFER is like 4XX. Wietse
Re: postscreen deep protocol tests and Amazon timeouts
Am 16.09.2014 um 12:47 schrieb LuKreme: > On 15 Sep 2014, at 14:31 , Andrew J. Schorr > wrote: >> I could be wrong, but if greylisting works reliably, > > And there we get to the root of the problem. It does not work reliably > because it ignores how large companies like Google and Yahoo and Amazon send > mail. Greylisting, *BY DESIGN* screws up large company email. The entire > basis of greylisting is that a single mail server sends email, and that is > just not how email works for large senders. > whats the problem, setup greylisting selective with smtpd_restriction_classes to typical dyn ip via pcr table etc, and have fun with postscreen too Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
AW: postscreen deep protocol tests and Amazon timeouts
> -Ursprüngliche Nachricht- > Von: owner-postfix-us...@postfix.org [mailto:owner-postfix- > us...@postfix.org] Im Auftrag von LuKreme > Gesendet: Dienstag, 16. September 2014 12:48 > An: postfix-users@postfix.org > Betreff: Re: postscreen deep protocol tests and Amazon timeouts > > On 15 Sep 2014, at 14:31 , Andrew J. Schorr investments.com> wrote: > > I could be wrong, but if greylisting works reliably, > > And there we get to the root of the problem. It does not work reliably > because it ignores how large companies like Google and Yahoo and Amazon > send mail. Greylisting, *BY DESIGN* screws up large company email. The > entire basis of greylisting is that a single mail server sends email, and that is > just not how email works for large senders. > If my Server had a problem the big sender becomes the same error like greylisting If the big sender can not handle it they breaks the RFC not I. They want to SEND a mail to me so I make the rules !! The law is for Every one the same (I hope so ) E-Mail is not real time communication by design ! Mit freundlichen Grüßen Uwe Drießen -- Software & Computer Uwe Drießen Lembergstraße 33 67824 Feilbingert Tel.: 06708660045
Re: postscreen deep protocol tests and Amazon timeouts
Am 16.09.2014 um 13:41 schrieb Uwe Drießen: >> just not how email works for large senders. > > If my Server had a problem the big sender becomes the > same error like greylisting no, because he just tries later or another MX > If the big sender can not handle it they breaks the RFC not I. > They want to SEND a mail to me so I make the rules !! they can handle it and they don't break any RFC because the RFC just says "try later" and not "try later with the same client IP" > The law is for Every one the same (I hope so ) > E-Mail is not real time communication by design! the problem with a large sending cluster is not real time in case of Greylisting, the problem is that each delivery attempt may come from a different cluster node and the bigger the cluster the more likely is that they never make it through your "interpretation of RFC"
Re: postscreen deep protocol tests and Amazon timeouts
Am 16.09.2014 um 13:41 schrieb Uwe Drießen: > E-Mail is not real time communication by design ! the problem is ,users are ignorant to this *g Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: postscreen deep protocol tests and Amazon timeouts
> On 16 Sep 2014, at 05:41 , Uwe Drießen wrote: > >> -Ursprüngliche Nachricht- >> Von: owner-postfix-us...@postfix.org [mailto:owner-postfix- >> us...@postfix.org] Im Auftrag von LuKreme >> Gesendet: Dienstag, 16. September 2014 12:48 >> An: postfix-users@postfix.org >> Betreff: Re: postscreen deep protocol tests and Amazon timeouts >> >> On 15 Sep 2014, at 14:31 , Andrew J. Schorr > investments.com> wrote: >>> I could be wrong, but if greylisting works reliably, >> >> And there we get to the root of the problem. It does not work reliably >> because it ignores how large companies like Google and Yahoo and Amazon >> send mail. Greylisting, *BY DESIGN* screws up large company email. The >> entire basis of greylisting is that a single mail server sends email, and > that is >> just not how email works for large senders. >> > > If my Server had a problem the big sender becomes the same error like > greylisting > If the big sender can not handle it they breaks the RFC not I. > They want to SEND a mail to me so I make the rules !! This is fine if your server serves email to just you. But when a customer or a executive doesn’t get his email from Amazon or Google, you don’t get to say “They are not following the RFCs.” > E-Mail is not real time communication by design ! You’re living in the 90s. If someone is expecting an email and it’s delayed by 5 minutes I hear about it. Greylisting large companies like Google, Yahoo, Amazon, Apple, etc is *stupid*. -- Carlin's Third Commandment: Thou shall keep thy religion to thyself.
Re: postscreen deep protocol tests and Amazon timeouts
On September 16, 2014 2:03:36 PM Robert Schetterer wrote: Am 16.09.2014 um 13:41 schrieb Uwe Drießen: > E-Mail is not real time communication by design ! the problem is ,users are ignorant to this *g Never seen a time limithed offer ?
Where is postfix / lmtp trying to deliver mail?
Under centOS 6.5, I'm trying to get postfix to play nicely with LDAP and cyrus-imapd (please don't say "Use dovecot", I can't) Postfix is authenticating against LDAP just fine and was writing Maildir mailboxes where I expected it to, and then I changed the transport to lmtp mydestination = $myhostname, localhost.$mydomain, localhost virtual_mailbox_domains = $mydomain virtual_mailbox_base = /var/vmail/ virtual_mailbox_maps = ldap:/etc/postfix/ldap-users.cf virtual_uid_maps = static:504 virtual_gid_maps = static:505 virtual_transport = lmtp:unix:/var/lib/imap/socket/lmtp I created Cyrus mailboxes in /var/vmail, and cyrus-imapd can read them. But postfix cannot find them: Sep 16 09:48:13 localhost postfix/cleanup[8101]: B67D61EF1: message-id=<20140916164802.B67D61EF1@localhost.localdomain> Sep 16 09:48:13 localhost postfix/qmgr[15890]: B67D61EF1: from=, size=356, nrcpt=1 (queue active) Sep 16 09:48:13 localhost postfix/smtpd[8094]: public/cleanup socket: wanted attribute: status Sep 16 09:48:13 localhost postfix/smtpd[8094]: input attribute name: status Sep 16 09:48:13 localhost postfix/smtpd[8094]: input attribute value: 0 Sep 16 09:48:13 localhost postfix/smtpd[8094]: public/cleanup socket: wanted attribute: reason Sep 16 09:48:13 localhost postfix/smtpd[8094]: input attribute name: reason Sep 16 09:48:13 localhost postfix/smtpd[8094]: input attribute value: (end) Sep 16 09:48:13 localhost postfix/smtpd[8094]: public/cleanup socket: wanted attribute: (list terminator) Sep 16 09:48:13 localhost postfix/smtpd[8094]: input attribute name: (end) Sep 16 09:48:13 localhost postfix/smtpd[8094]: > localhost[::1]: 250 2.0.0 Ok: queued as B67D61EF1 Sep 16 09:48:14 localhost lmtpunix[16091]: accepted connection Sep 16 09:48:14 localhost lmtpunix[16091]: lmtp connection preauth'd as postman Sep 16 09:48:14 localhost lmtpunix[16091]: verify_user(user.testuser2) failed: Mailbox does not exist Sep 16 09:48:14 localhost master[8104]: about to exec /usr/lib/cyrus-imapd/lmtpd Sep 16 09:48:14 localhost lmtpunix[8104]: executed Sep 16 09:48:14 localhost postfix/lmtp[8103]: B67D61EF1: to=, relay=localhost.localdomain[/var/lib/imap/socket/lmtp], delay=21, delays=21/0.03/0/0.03, dsn=5.1.1, status=bounced (host localhost.localdomain[/var/lib/imap/socket/lmtp] said: 550-Mailbox unknown. Either there is no mailbox associated with this 550-name or you do not have authorization to see it. 550 5.1.1 User unknown (in reply to RCPT TO command)) Sep 16 09:48:14 localhost postfix/cleanup[8101]: 09EFD1EFC: message-id=<20140916164814.09EFD1EFC@localhost.localdomain> Sep 16 09:48:14 localhost postfix/bounce[8105]: B67D61EF1: sender non-delivery notification: 09EFD1EFC Sep 16 09:48:14 localhost postfix/qmgr[15890]: B67D61EF1: removed Sep 16 09:48:14 localhost postfix/qmgr[15890]: 09EFD1EFC: from=<>, size=2545, nrcpt=1 (queue active) Sep 16 09:48:14 localhost postfix/smtp[8106]: 09EFD1EFC: to=, relay=none, delay=0.09, delays=0/0/0.08/0, dsn=5.4.4, status=bounced (Host or domain name not found. Name service error for name=test.zzz type=: Host not found) Sep 16 09:48:14 localhost postfix/qmgr[15890]: 09EFD1EFC: removed Sep 16 09:48:16 localhost postfix/smtpd[8094]: < localhost[::1]: quit Sep 16 09:48:16 localhost postfix/smtpd[8094]: > localhost[::1]: 221 2.0.0 Bye Sep 16 09:48:16 localhost postfix/smtpd[8094]: match_hostname: localhost ~? 127.0.0.0/8 Sep 16 09:48:16 localhost postfix/smtpd[8094]: match_hostaddr: ::1 ~? 127.0.0.0/8 Sep 16 09:48:16 localhost postfix/smtpd[8094]: match_hostname: localhost ~? [::1]/128 Sep 16 09:48:16 localhost postfix/smtpd[8094]: match_hostaddr: ::1 ~? [::1]/128 Sep 16 09:48:16 localhost postfix/smtpd[8094]: disconnect from localhost[::1] Sep 16 09:48:16 localhost postfix/smtpd[8094]: master_notify: status 1 Sep 16 09:48:16 localhost postfix/smtpd[8094]: connection closed Sep 16 09:48:16 localhost postfix/smtpd[8094]: proxymap stream disconnect Sep 16 09:48:16 localhost postfix/smtpd[8094]: rewrite stream disconnect How do I find out WHERE it's looking for the mailbox? Is there a separate config for lmtp I'm not seeing? -- *** * John Oliver http://www.john-oliver.net/ * * * ***
Re: Where is postfix / lmtp trying to deliver mail?
John Oliver: > virtual_mailbox_domains = $mydomain > virtual_mailbox_base = /var/vmail/ > virtual_mailbox_maps = ldap:/etc/postfix/ldap-users.cf > virtual_uid_maps = static:504 > virtual_gid_maps = static:505 The above settings are for the Postfix virtual(8) delivery agent. > virtual_transport = lmtp:unix:/var/lib/imap/socket/lmtp You are not using the Postfix virtual(8) delivery agent, so Postfix uses only the virtual_mailbox_maps setting (so that it knows what addresses to receive). > relay=localhost.localdomain[/var/lib/imap/socket/lmtp], delay=21, > delays=21/0.03/0/0.03, dsn=5.1.1, status=bounced (host > localhost.localdomain[/var/lib/imap/socket/lmtp] said: 550-Mailbox > unknown. Either there is no mailbox associated with this 550-name or > you do not have authorization to see it. 550 5.1.1 User unknown (in > reply to RCPT TO command)) This is the cyrus-imapd delivery agent complaining. You did not configure cyrus-imapd correctly for this user. Wietse
FYI: blocking attachment extensions
(yes i know it's not 100% perfect in any case) but anybody using "mime_header_checks" by one of the similar howtos out there should review the configuration - without \" at the end of the regex this is prone to false positives two examples from real world (.scr and .com wrongly rejected) * name="strace.Scripting-with-the-xss.pdf.txt" * filename="BOOKING.COM: Hotel 342802.PDF" i think this was the one i followed http://www.cyberciti.biz/tips/postfix-block-mime-attachment-files.html _ cat /etc/postfix/mime_header_checks.cf # Reject Attachment-Extensions /name=[^>]*\.(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|msc|msi|msp|mst|ocx|pcd|pif|pl|reg|scr|script|sct|sh|shb|shs|sys|so|tlb|vb|vbe|vbs|wiz|wll|wpc|wsc|wsf|wsh)\"/ REJECT 554 Attachment Blocked
Re: FYI: blocking attachment extensions
li...@rhsoft.net: > (yes i know it's not 100% perfect in any case) > > but anybody using "mime_header_checks" by one of the similar howtos out > there should review the configuration - without \" at the end of the > regex this is prone to false positives Caution: MIME allows names in this context without "", as long as those names contain no whitespace etc. Wietse > two examples from real world (.scr and .com wrongly rejected) > > * name="strace.Scripting-with-the-xss.pdf.txt" > * filename="BOOKING.COM: Hotel 342802.PDF" > > i think this was the one i followed > http://www.cyberciti.biz/tips/postfix-block-mime-attachment-files.html > _ > > cat /etc/postfix/mime_header_checks.cf > # Reject Attachment-Extensions > /name=[^>]*\.(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|msc|msi|msp|mst|ocx|pcd|pif|pl|reg|scr|script|sct|sh|shb|shs|sys|so|tlb|vb|vbe|vbs|wiz|wll|wpc|wsc|wsf|wsh)\"/ > REJECT 554 Attachment Blocked > > >
Re: FYI: blocking attachment extensions
Am 16.09.2014 um 20:34 schrieb Wietse Venema: > li...@rhsoft.net: >> (yes i know it's not 100% perfect in any case) >> >> but anybody using "mime_header_checks" by one of the similar howtos out >> there should review the configuration - without \" at the end of the >> regex this is prone to false positives > > Caution: MIME allows names in this context without "", as long as > those names contain no whitespace etc. thanks for the hint i am open for suggestions how to optimize that in general without raise false positives - at the end there is clamd but "mime_header_checks" is "cheaper" >> two examples from real world (.scr and .com wrongly rejected) >> >> * name="strace.Scripting-with-the-xss.pdf.txt" >> * filename="BOOKING.COM: Hotel 342802.PDF" >> >> i think this was the one i followed >> http://www.cyberciti.biz/tips/postfix-block-mime-attachment-files.html >> _ >> >> cat /etc/postfix/mime_header_checks.cf >> # Reject Attachment-Extensions >> /name=[^>]*\.(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|msc|msi|msp|mst|ocx|pcd|pif|pl|reg|scr|script|sct|sh|shb|shs|sys|so|tlb|vb|vbe|vbs|wiz|wll|wpc|wsc|wsf|wsh)\"/ >> REJECT 554 Attachment Blocked
Re: FYI: blocking attachment extensions
On 9/16/2014 1:04 PM, li...@rhsoft.net wrote: > (yes i know it's not 100% perfect in any case) > > but anybody using "mime_header_checks" by one of the similar howtos out > there should review the configuration - without \" at the end of the > regex this is prone to false positives > > two examples from real world (.scr and .com wrongly rejected) > > * name="strace.Scripting-with-the-xss.pdf.txt" > * filename="BOOKING.COM: Hotel 342802.PDF" > > i think this was the one i followed > http://www.cyberciti.biz/tips/postfix-block-mime-attachment-files.html > _ > > cat /etc/postfix/mime_header_checks.cf > # Reject Attachment-Extensions > /name=[^>]*\.(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|msc|msi|msp|mst|ocx|pcd|pif|pl|reg|scr|script|sct|sh|shb|shs|sys|so|tlb|vb|vbe|vbs|wiz|wll|wpc|wsc|wsf|wsh)\"/ > REJECT 554 Attachment Blocked > > Be aware the quote marks are optional, and there may be mime options following the file name. And maybe QP encoded too. Getting all the possible valid combinations is probably impossible without some sort of mime normalizer. I've used the below for a few years with good results. It's better, but surely not perfect. # block windows executables PCRE /^\s*Content-(Disposition|Type).*name\s*=\s*"?(.*(\.|=2E)( ade|adp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|hlp|hta| inf|ins|isp|js|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws| ops|pcd|pif|prf|reg|scf|scr|sct|shb|shs|shm|swf| vb|vbe|vbs|vbx|vxd|wsc|wsf|wsh))(\?=)?"?\s*$/x REJECT Attachment name "$2" not allowed -- Noel Jones
Re: FYI: blocking attachment extensions
On Tue, Sep 16, 2014 at 01:41:36PM -0500, Noel Jones wrote: > I've used the below for a few years with good results. It's better, > but surely not perfect. > > > # block windows executables PCRE > /^\s*Content-(Disposition|Type).*name\s*=\s*"?(.*(\.|=2E)( > ade|adp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|hlp|hta| > inf|ins|isp|js|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws| > ops|pcd|pif|prf|reg|scf|scr|sct|shb|shs|shm|swf| > vb|vbe|vbs|vbx|vxd|wsc|wsf|wsh))(\?=)?"?\s*$/x This assumes that "name" or "filename" is the last attribute in the header. It might instead be followed by a ";" and more attributes. So for a bit more generality, try the below: # block windows executables PCRE /^\s*Content-(?:Disposition|Type): # Header label (?:.*?;)? \s* # Any prior attributes (?:file)?name\s*=\s*"?# name or filename (# Capture name for response .*?(\.|=2E)# File basename and "." (ade|adp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|hlp|hta| inf|ins|isp|js|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws| ops|pcd|pif|prf|reg|scf|scr|sct|shb|shs|shm|swf| vb|vbe|vbs|vbx|vxd|wsc|wsf|wsh) # Capture risky extensions )# Close capture (?:\?=)? # Trailer of ad-hoc RFC 2047 encoding "? # Optional close quote \s*(;|$) # End of attribute or header /x [ untested ] -- Viktor.
Re: FYI: blocking attachment extensions
Am 16.09.2014 um 21:00 schrieb Viktor Dukhovni: > On Tue, Sep 16, 2014 at 01:41:36PM -0500, Noel Jones wrote: > >> I've used the below for a few years with good results. It's better, >> but surely not perfect. >> >> # block windows executables PCRE >> /^\s*Content-(Disposition|Type).*name\s*=\s*"?(.*(\.|=2E)( >> ade|adp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|hlp|hta| >> inf|ins|isp|js|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws| >> ops|pcd|pif|prf|reg|scf|scr|sct|shb|shs|shm|swf| >> vb|vbe|vbs|vbx|vxd|wsc|wsf|wsh))(\?=)?"?\s*$/x > > This assumes that "name" or "filename" is the last attribute in > the header. It might instead be followed by a ";" and more > attributes. So for a bit more generality, try the below: > > # block windows executables PCRE > /^\s*Content-(?:Disposition|Type):# Header label > (?:.*?;)? \s* # Any prior attributes > (?:file)?name\s*=\s*"? # name or filename >( # Capture name for response >.*?(\.|=2E)# File basename and "." > (ade|adp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|hlp|hta| > inf|ins|isp|js|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws| > ops|pcd|pif|prf|reg|scf|scr|sct|shb|shs|shm|swf| > vb|vbe|vbs|vbx|vxd|wsc|wsf|wsh) # Capture risky extensions >) # Close capture >(?:\?=)? # Trailer of ad-hoc RFC 2047 > encoding >"? # Optional close quote >\s*(;|$) # End of attribute or header > /x > > [ untested ] thanks! interesting - none of both blocking a empty textfile renamed to "test.exe" i have all 3 for now enabled and the 3rd one rejects (Thunderbird as MUA) reject: header Content-Type: application/octet-stream;? name="test.exe" 5.7.1 554 Attachment Blocked (Rule 3) [root@localhost:~]$ cat postfix/mime_header_checks.cf # Reject Attachment Extensions /^\s*Content-(Disposition|Type).*name\s*=\s*"?(.*(\.|=2E)(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cmd|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|ocx|ops|pcd|pif|pl|prf|reg|scf|scr|script|sct|sh|shb|shm|shs|so|sys|tlb|vb|vbe|vbs|vbx|vxd|wiz|wll|wpc|wsc|wsf|wsh))(\?=)?"?\s*$/x REJECT 554 Attachment Blocked (Rule 1) /^\s*Content-(?:Disposition|Type):(?:.*?;)?\s*(?:file)?name\s*=\s*"?(.*?(\.|=2E)(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cmd|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|ocx|ops|pcd|pif|pl|prf|reg|scf|scr|script|sct|sh|shb|shm|shs|so|sys|tlb|vb|vbe|vbs|vbx|vxd|wiz|wll|wpc|wsc|wsf|wsh))(?:\?=)?"?\s*(;|$)/x REJECT 554 Attachment Blocked (Rule 2) /name=[^>]*\.(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cmd|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|ocx|ops|pcd|pif|pl|prf|reg|scf|scr|script|sct|sh|shb|shm|shs|so|sys|tlb|vb|vbe|vbs|vbx|vxd|wiz|wll|wpc|wsc|wsf|wsh)\"/ REJECT 554 Attachment Blocked (Rule 3)
Re: FYI: blocking attachment extensions
On Tue, Sep 16, 2014 at 09:28:11PM +0200, li...@rhsoft.net wrote:
> > # block windows executables PCRE
> > /^\s*Content-(?:Disposition|Type): # Header label
> > (?:.*?;)? \s* # Any prior attributes
> > (?:file)?name\s*=\s*"?# name or filename
> >(# Capture name for response
> > .*?(\.|=2E)# File basename and "."
> > (ade|adp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|hlp|hta|
> > inf|ins|isp|js|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|
> > ops|pcd|pif|prf|reg|scf|scr|sct|shb|shs|shm|swf|
> > vb|vbe|vbs|vbx|vxd|wsc|wsf|wsh) # Capture risky extensions
> >)# Close capture
> >(?:\?=)? # Trailer of ad-hoc RFC 2047
> > encoding
> >"? # Optional close quote
> >\s*(;|$) # End of attribute or header
> > /x
> >
> > [ untested ]
>
> thanks!
>
> interesting - none of both blocking a empty textfile renamed to "test.exe"
> i have all 3 for now enabled and the 3rd one rejects (Thunderbird as MUA)
That's because Postfix does not support in-line comments in PCRE
patterns. The multi-line pattern is unfolded first, and the first
comment gobbles up all the remaining text. If you strip all the
comments:
$ postmap -q 'Content-Type: name="test.exe.txt"; charset=us-ascii'
pcre:/tmp/foo.pcre
$ postmap -q 'Content-Type: name="test.exe"; charset=us-ascii'
pcre:/tmp/foo.pcre
REJECT blocked filename test.exe
With /tmp/foo.pcre containing:
# block windows executables PCRE
/^Content-(?:Disposition|Type):
(?:.*?;)? \s*
(?:file)?name \s* = \s*"?
(
.*?(\.|=2E)
(ade|adp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|hlp|hta|
inf|ins|isp|js|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|
ops|pcd|pif|prf|reg|scf|scr|sct|shb|shs|shm|swf|
vb|vbe|vbs|vbx|vxd|wsc|wsf|wsh)
)
(?:\?=)?
"?
\s*(;|$)
/x REJECT blocked filename ${1}
--
Viktor.
Re: FYI: blocking attachment extensions
Viktor Dukhovni: > > interesting - none of both blocking a empty textfile renamed to "test.exe" > > i have all 3 for now enabled and the 3rd one rejects (Thunderbird as MUA) > > That's because Postfix does not support in-line comments in PCRE > patterns. The multi-line pattern is unfolded first, and the first > comment gobbles up all the remaining text. If you strip all the > comments: You can put the comment on the line before the code that the comment applies to. #comment code Wietse
Re: Why does EHLO [X.X.X.X] always pass helo restrictions?
On Sep 14, 2014, at 2:17 AM, li...@rhsoft.net wrote: > > > Am 14.09.2014 um 01:54 schrieb Philip Prindeville: >> On Sep 13, 2014, at 7:35 AM, li...@rhsoft.net wrote: >>> Am 13.09.2014 um 15:10 schrieb LuKreme: On 12 Sep 2014, at 13:55 , li...@rhsoft.net wrote: > Am 12.09.2014 um 21:49 schrieb Philip Prindeville: >>> However, any time I connect via telnet to this server and specify >>> *any* IP address in the form [X.X.X.X], the smtpd_helo_restrictions >>> won't trigger. >> This is both legal and reasonable. > > it maybe true but it is *not* reasonable What do you base that on? > >> Who says anything about mail servers? > > the topic by definition Really? I missed the part where the topic said "MTA-to-MTA exclusively”… > >> What if it’s an MUA doing this? > > a MUA is using authentication and that is why you have > *permit_sasl_authenticated* before such restrictions It’s why you MIGHT have it. You’re not required to by any protocol standard or universal policy. > > see the last paragraph of my post which refers to default settings > and behavior of postfix, so the next time please hestitate to step > into a topic saying something is completly reasonable by lack > understand the topic Or perhaps you could be more specific and a little less arrogant. The default settings you mentioned were for the RECEIVING MTA. That receiving MTA might be speaking to either a SENDING MTA or a SUBMITTING MUA. And maybe you’re the one lacking understanding of the FULL SCOPE in which these settings might be used. > >>> you stripped that part from my quote >>> because it is *easy* to do it right >> >> It’s EASIER to do if you know your topology. It’s impossible to do >> with absolute certainty if you don’t > > if you don't know your topology don't setup a MTA Again, you’re confounding things. This is a setting on the RECEIVING MTA. A “EHLO” transaction is generated, by DEFINITION, from either a SENDING MTA or a SUBMITTING MUA, which the RECEIVING MTA has no control over. > >>> if someone is not able to determine his public >>> hostname and IP he better don't setup a MTA >> >> Again, it’s not just MTA’s which speak SMTP… > > again - only MTA's have to deliver unauthenticated mail But they have to communicate with both sending MTA’s and submitting MUA’s. You don’t know if you’re in the delivery step until AFTER you’ve seen the EHLO, AFTER you’ve seen the MAIL FROM, AFTER you’ve seen the RCPT TO, and AFTER you’ve seen the DOT (since their might be restrictions on content type, content length, etc). So whether it’s ultimately a delivery transaction or not is not determined at the moment an MTA has seen an EHLO… > >>> the same way as your internel PTR and A record don't count in >>> the internet your internal hostname also is not relevant - set >>> the HELO name to the public one matching the public DNS redcords >>> and if you don't know where to do so don't setup a public mail server >> >> What if you’re on an ISP (like Comcast residential) which won’t give you a >> fixed address? > > than you don't have to run a MTA, hence that rules > if you runa MTA there then you have to use a smarthost for delivery AGAIN, the controls you’re talking about are about the RECEIVING MTA getting a specific type of EHLO which is generated BY THE REMOTE SIDE. This has nothing to do with the configuration of the receiving MTA and everything to do with the REMOTE PEER. Which part of this should I draw a picture for? > > if you are a legit MUA you have to use SMTP auth and so the > rule sdon't affect you You’re confusing both sending and receiving roles, and failing to differentiate per-site policy from protocol (which is universal). > What problem are you having that you are trying to solve? >>> >>> have you ever seen a non-spam connection on a inbound MX with >>> such a HELO - yes it happens 1 out of 10 and only because >>> people continue to tell it is reasonable instead block such >>> connections >> >> Yeah, all the time. Each of the company employees when >> he’s out-of-office and connecting remotely. > > that is pure bullshit in that case they are using SMTP > authentication and so they are not affected by MTA rules > or otherwise fire your mailadmin > > please come back after read some prerequisite for a topic like this I’ve been doing this a long time… I’ve contributed to Thunderbird, Fedora, Sendmail, Postfix, MMDF, Qmailer, Cyrus, MAIL-11, Zmail… and a couple of the MIME and Mail RFC’s. I’ve also had to see a great many corner cases. > >> You’re forgetting that UNTIL you’ve seen the MAIL FROM and RCPT TO, >> you don’t know if this is a CLIENT submitting the message to the >> OUTBOUND MTA, or another MTA attempting FINAL DELIVERY. > > bullshit - the MUA is using authentication Not necessarily. You might be using their IP address and doing lookups in MIMEDefang (if the MUA’s are at fixed remote loc
Re: Why does EHLO [X.X.X.X] always pass helo restrictions?
Philip Prindeville: > > On Sep 14, 2014, at 2:17 AM, li...@rhsoft.net wrote: HEY! Take if off-list. Wietse
Re: Why does EHLO [X.X.X.X] always pass helo restrictions?
Am 16.09.2014 um 21:48 schrieb Philip Prindeville: > On Sep 14, 2014, at 2:17 AM, li...@rhsoft.net wrote: > >> Am 14.09.2014 um 01:54 schrieb Philip Prindeville: >>> On Sep 13, 2014, at 7:35 AM, li...@rhsoft.net wrote: Am 13.09.2014 um 15:10 schrieb LuKreme: > On 12 Sep 2014, at 13:55 , li...@rhsoft.net wrote: >> Am 12.09.2014 um 21:49 schrieb Philip Prindeville: However, any time I connect via telnet to this server and specify *any* IP address in the form [X.X.X.X], the smtpd_helo_restrictions won't trigger. >>> This is both legal and reasonable. >> >> it maybe true but it is *not* reasonable > > What do you base that on? >> >>> Who says anything about mail servers? >> >> the topic by definition > > > Really? I missed the part where the topic said "MTA-to-MTA exclusively" logical conclusion because a MUA is using all sort of weird HELO names and typically falls into "permit_mynetworks" or "permit_sasl_authenticated" since it needs one of both to send mail outside the own domain without setup a open relay >>> What if it’s an MUA doing this? >> >> a MUA is using authentication and that is why you have >> *permit_sasl_authenticated* before such restrictions > > > It’s why you MIGHT have it. You’re not required to by any protocol standard > or universal policy. it's a common setup >> see the last paragraph of my post which refers to default settings >> and behavior of postfix, so the next time please hestitate to step >> into a topic saying something is completly reasonable by lack >> understand the topic > > Or perhaps you could be more specific and a little less arrogant. > > The default settings you mentioned were for the RECEIVING MTA. That receiving > MTA might be > speaking to either a SENDING MTA or a SUBMITTING MUA. i am not the OP the OP pretty clear talked about MTA to MTA by context i just refused "it is reasonable" in the context > And maybe you’re the one lacking understanding of the FULL SCOPE in which > these settings might be used. no - such settings are by definition for MTA-to-MTA because any of them would break most MUA in general you stripped that part from my quote because it is *easy* to do it right >>> >>> It’s EASIER to do if you know your topology. It’s impossible to do >>> with absolute certainty if you don’t >> >> if you don't know your topology don't setup a MTA > > Again, you’re confounding things. This is a setting on the RECEIVING MTA. and only a sending MTA completly weird configured is affected a MUA has different settings and should not use port 25 at all > A “EHLO” transaction is generated, by DEFINITION, from either a SENDING MTA > or a SUBMITTING MUA, which the RECEIVING MTA has no control over. yes, but that don't change the fact that MUA and MTA senders are handeled different if someone is not able to determine his public hostname and IP he better don't setup a MTA >>> >>> Again, it’s not just MTA’s which speak SMTP… >> >> again - only MTA's have to deliver unauthenticated mail > > But they have to communicate with both sending MTA’s and submitting MUA’s not in the context > You don’t know if you’re in the delivery step until AFTER you’ve seen the > EHLO, AFTER you’ve seen the MAIL > FROM, AFTER you’ve seen the RCPT TO, and AFTER you’ve seen the DOT (since > their might be restrictions on > content type, content length, etc). that's why postfix makes the decision AFTER all of that > So whether it’s ultimately a delivery transaction or not is not determined at > the moment an MTA has seen an EHLO… no the same way as your internel PTR and A record don't count in the internet your internal hostname also is not relevant - set the HELO name to the public one matching the public DNS redcords and if you don't know where to do so don't setup a public mail server >>> >>> What if you’re on an ISP (like Comcast residential) which won’t give you a >>> fixed address? >> >> than you don't have to run a MTA, hence that rules >> if you runa MTA there then you have to use a smarthost for delivery > > AGAIN, the controls you’re talking about are about the RECEIVING MTA getting > a specific type of EHLO which is generated BY THE REMOTE SIDE. AGAIN a MUA is handeled different to a MTA > This has nothing to do with the configuration of the receiving MTA and > everything to do with the REMOTE PEER. > Which part of this should I draw a picture for? no need >> if you are a legit MUA you have to use SMTP auth and so the >> rule sdon't affect you > > You’re confusing both sending and receiving roles, and failing to > differentiate > per-site policy from protocol (which is universal). i confuse nothing, i have both in mind and which rules can be applied and how > What problem are you having that you are trying to solve? have you ever seen a non-spam connection on a inbound MX with such a HELO - yes it happens 1 out of 1
Re: FYI: blocking attachment extensions
Am 16.09.2014 um 21:42 schrieb Viktor Dukhovni:
> On Tue, Sep 16, 2014 at 09:28:11PM +0200, li...@rhsoft.net wrote:
>
>>> # block windows executables PCRE
>>> /^\s*Content-(?:Disposition|Type): # Header label
>>> (?:.*?;)? \s* # Any prior attributes
>>> (?:file)?name\s*=\s*"?# name or filename
>>>(# Capture name for response
>>> .*?(\.|=2E)# File basename and "."
>>> (ade|adp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|hlp|hta|
>>> inf|ins|isp|js|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|
>>> ops|pcd|pif|prf|reg|scf|scr|sct|shb|shs|shm|swf|
>>> vb|vbe|vbs|vbx|vxd|wsc|wsf|wsh) # Capture risky extensions
>>>)# Close capture
>>>(?:\?=)? # Trailer of ad-hoc RFC 2047
>>> encoding
>>>"? # Optional close quote
>>>\s*(;|$) # End of attribute or header
>>> /x
>>>
>>> [ untested ]
>>
>> thanks!
>>
>> interesting - none of both blocking a empty textfile renamed to "test.exe"
>> i have all 3 for now enabled and the 3rd one rejects (Thunderbird as MUA)
>
> That's because Postfix does not support in-line comments in PCRE
> patterns. The multi-line pattern is unfolded first, and the first
> comment gobbles up all the remaining text. If you strip all the
> comments:
>
> $ postmap -q 'Content-Type: name="test.exe.txt"; charset=us-ascii'
> pcre:/tmp/foo.pcre
> $ postmap -q 'Content-Type: name="test.exe"; charset=us-ascii'
> pcre:/tmp/foo.pcre
> REJECT blocked filename test.exe
>
> With /tmp/foo.pcre containing:
>
> # block windows executables PCRE
> /^Content-(?:Disposition|Type):
> (?:.*?;)? \s*
> (?:file)?name \s* = \s*"?
>(
>.*?(\.|=2E)
> (ade|adp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|hlp|hta|
> inf|ins|isp|js|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|
> ops|pcd|pif|prf|reg|scf|scr|sct|shb|shs|shm|swf|
> vb|vbe|vbs|vbx|vxd|wsc|wsf|wsh)
>)
>(?:\?=)?
>"?
>\s*(;|$)
> /x REJECT blocked filename ${1}
uhm i removed all comments AFAIK
that are 3 single lines without any break not added by the mail-client
i now attached it as a file and still only (Rule 3) hits
# Reject Attachment Extensions
/^Content-(?:Disposition|Type):
(?:.*?;)? \s*
(?:file)?name \s* = \s*"?
(
.*?(\.|=2E)
(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cmd|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|ocx|ops|pcd|pif|pl|prf|reg|scf|scr|script|sct|sh|shb|shm|shs|so|sys|tlb|vb|vbe|vbs|vbx|vxd|wiz|wll|wpc|wsc|wsf|wsh)
)
(?:\?=)?
"?
\s*(;|$)
/x REJECT 554 Attachment Blocked (Rule 0)
/^\s*Content-(Disposition|Type).*name\s*=\s*"?(.*(\.|=2E)(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cmd|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|ocx|ops|pcd|pif|pl|prf|reg|scf|scr|script|sct|sh|shb|shm|shs|so|sys|tlb|vb|vbe|vbs|vbx|vxd|wiz|wll|wpc|wsc|wsf|wsh))(\?=)?"?\s*$/x
REJECT 554 Attachment Blocked (Rule 1)
/^\s*Content-(?:Disposition|Type):(?:.*?;)?\s*(?:file)?name\s*=\s*"?(.*?(\.|=2E)(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cmd|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|ocx|ops|pcd|pif|pl|prf|reg|scf|scr|script|sct|sh|shb|shm|shs|so|sys|tlb|vb|vbe|vbs|vbx|vxd|wiz|wll|wpc|wsc|wsf|wsh))(?:\?=)?"?\s*(;|$)/x
REJECT 554 Attachment Blocked (Rule 2)
/name=[^>]*\.(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cmd|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|ocx|ops|pcd|pif|pl|prf|reg|scf|scr|script|sct|sh|shb|shm|shs|so|sys|tlb|vb|vbe|vbs|vbx|vxd|wiz|wll|wpc|wsc|wsf|wsh)\"/
REJECT 554 Attachment Blocked (Rule 3)
Re: FYI: blocking attachment extensions
On Tue, Sep 16, 2014 at 10:15:03PM +0200, li...@rhsoft.net wrote: > I removed all comments AFAIK > that are 3 single lines without any break not added by the mail-client I've copied the rule below into my test file, and it works: $ postmap -q 'Content-Type: name="test.exe"; charset=us-ascii' pcre:/tmp/foo.pcre REJECT 554 Attachment Blocked (Rule 0) You've not posted your test input or postmap -q invocation with output. > # Reject Attachment Extensions > > /^Content-(?:Disposition|Type): > (?:.*?;)? \s* > (?:file)?name \s* = \s*"? >( >.*?(\.|=2E) > > (386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cmd|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|ocx|ops|pcd|pif|pl|prf|reg|scf|scr|script|sct|sh|shb|shm|shs|so|sys|tlb|vb|vbe|vbs|vbx|vxd|wiz|wll|wpc|wsc|wsf|wsh) >) >(?:\?=)? >"? >\s*(;|$) > /x REJECT 554 Attachment Blocked (Rule 0) > > /^\s*Content-(Disposition|Type).*name\s*=\s*"?(.*(\.|=2E)(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cmd|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|ocx|ops|pcd|pif|pl|prf|reg|scf|scr|script|sct|sh|shb|shm|shs|so|sys|tlb|vb|vbe|vbs|vbx|vxd|wiz|wll|wpc|wsc|wsf|wsh))(\?=)?"?\s*$/x > REJECT 554 Attachment Blocked (Rule 1) > > /^\s*Content-(?:Disposition|Type):(?:.*?;)?\s*(?:file)?name\s*=\s*"?(.*?(\.|=2E)(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cmd|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|ocx|ops|pcd|pif|pl|prf|reg|scf|scr|script|sct|sh|shb|shm|shs|so|sys|tlb|vb|vbe|vbs|vbx|vxd|wiz|wll|wpc|wsc|wsf|wsh))(?:\?=)?"?\s*(;|$)/x > REJECT 554 Attachment Blocked (Rule 2) > > /name=[^>]*\.(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cmd|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|ocx|ops|pcd|pif|pl|prf|reg|scf|scr|script|sct|sh|shb|shm|shs|so|sys|tlb|vb|vbe|vbs|vbx|vxd|wiz|wll|wpc|wsc|wsf|wsh)\"/ > REJECT 554 Attachment Blocked (Rule 3) -- Viktor.
Re: FYI: blocking attachment extensions
Am 16.09.2014 um 22:28 schrieb Viktor Dukhovni: > On Tue, Sep 16, 2014 at 10:15:03PM +0200, li...@rhsoft.net wrote: > >> I removed all comments AFAIK >> that are 3 single lines without any break not added by the mail-client > > I've copied the rule below into my test file, and it works: > > $ postmap -q 'Content-Type: name="test.exe"; charset=us-ascii' > pcre:/tmp/foo.pcre > REJECT 554 Attachment Blocked (Rule 0) > > You've not posted your test input or postmap -q invocation with output. i just created a new empty file, named it "test.exe" and attached it to a mail in Tunderbird, only Rule 3 hits - hence the numbering your input does not contain what thunderbird passes no idea what the ? is for in the log, i just can't reproduce only Rule 3 hitting like with using the MUA Sep 16 22:13:02 mail-gw postfix/cleanup[16214]: 3hyFxB6g0cz1y: reject: header Content-Type: application/octet-stream;? name="test.exe" from *.*.*.*; from=<***> to=<***> proto=ESMTP helo=: 5.7.1 554 Attachment Blocked (Rule 3) [root@mail-gw:~]$ postmap -q 'Content-Type: name="test.exe"; charset=us-ascii' pcre:/etc/postfix/mime_header_checks.cf REJECT 554 Attachment Blocked (Rule 0) [root@mail-gw:~]$ postmap -q 'Content-Type: application/octet-stream;? name="test.exe"' pcre:/etc/postfix/mime_header_checks.cf REJECT 554 Attachment Blocked (Rule 1) [root@mail-gw:~]$ postmap -q 'Content-Type: application/octet-stream; name="test.exe"' pcre:/etc/postfix/mime_header_checks.cf REJECT 554 Attachment Blocked (Rule 0) >> # Reject Attachment Extensions >> >> /^Content-(?:Disposition|Type): >> (?:.*?;)? \s* >> (?:file)?name \s* = \s*"? >>( >>.*?(\.|=2E) >> >> (386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cmd|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|ocx|ops|pcd|pif|pl|prf|reg|scf|scr|script|sct|sh|shb|shm|shs|so|sys|tlb|vb|vbe|vbs|vbx|vxd|wiz|wll|wpc|wsc|wsf|wsh) >>) >>(?:\?=)? >>"? >>\s*(;|$) >> /x REJECT 554 Attachment Blocked (Rule 0) >> >> /^\s*Content-(Disposition|Type).*name\s*=\s*"?(.*(\.|=2E)(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cmd|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|ocx|ops|pcd|pif|pl|prf|reg|scf|scr|script|sct|sh|shb|shm|shs|so|sys|tlb|vb|vbe|vbs|vbx|vxd|wiz|wll|wpc|wsc|wsf|wsh))(\?=)?"?\s*$/x >> REJECT 554 Attachment Blocked (Rule 1) >> >> /^\s*Content-(?:Disposition|Type):(?:.*?;)?\s*(?:file)?name\s*=\s*"?(.*?(\.|=2E)(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cmd|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|ocx|ops|pcd|pif|pl|prf|reg|scf|scr|script|sct|sh|shb|shm|shs|so|sys|tlb|vb|vbe|vbs|vbx|vxd|wiz|wll|wpc|wsc|wsf|wsh))(?:\?=)?"?\s*(;|$)/x >> REJECT 554 Attachment Blocked (Rule 2) >> >> /name=[^>]*\.(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cmd|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|ocx|ops|pcd|pif|pl|prf|reg|scf|scr|script|sct|sh|shb|shm|shs|so|sys|tlb|vb|vbe|vbs|vbx|vxd|wiz|wll|wpc|wsc|wsf|wsh)\"/ >> REJECT 554 Attachment Blocked (Rule 3)
Re: FYI: blocking attachment extensions
On Tue, Sep 16, 2014 at 10:41:01PM +0200, li...@rhsoft.net wrote: > > $ postmap -q 'Content-Type: name="test.exe"; charset=us-ascii' > > pcre:/tmp/foo.pcre > > REJECT 554 Attachment Blocked (Rule 0) > > > > You've not posted your test input or postmap -q invocation with output. > > I just created a new empty file, named it "test.exe" and attached it to > a mail in Thunderbird, only Rule 3 hits - hence the numbering. And where is your "postmap -q" test, with the verbatim header from the received message? > no idea what the ? is for in the log, i just can't reproduce only It stands for a newline (\n). > Rule 3 hitting like with using the MUA > > Sep 16 22:13:02 mail-gw postfix/cleanup[16214]: 3hyFxB6g0cz1y: reject: header > Content-Type: > application/octet-stream;? name="test.exe" Then the cleanup you're using does not have the right pattern, test with: $ postmap -q "$(printf 'Content-Type: application/octet-stream;\n\tname="test.exe"; charset=us-ascii')" pcre:/tmp/foo.pcre REJECT 554 Attachment Blocked (Rule 0) Perhaps you need to "postfix reload" or other pilot error. -- Viktor.
current best practice on the usage of the reject_unknown_hostname
hello all, I am used to have in the config reject_unknown_hostname in the smtpd_helo_restrictions and for literally years my mailserver were good. BUT in the last months, say from the start of the year i am rejecting more and more messages from reliable sources as the mail servers of pieces of italian government and some very big ISPs like FastWeb. My log files are filled with (example) Sep 16 06:42:00 server1 postfix/smtpd[4257]: NOQUEUE: reject: RCPT from wr001msr.fastwebnet.it[85.18.95.77]: 450 4.7.1 : Helo command rejected: Host not found; from= to= proto=ESMTP helo= for a transaction of a prefectly valid test email i sent to myself. More and more i see large installations with EHLOs to some local intranet names and thus not resolvable host names in dns provoking the reject in my postfix. Is it also your experience? Has reject_unknown_hostname less and less use in favour of other anti-spam methods? because in a server with 5000 mailbox and 80k-100k messages a day, that setting free me of 20k-30k spam messages easily, but catch these large institutions. i am just a bit confused. what is your experience on this? Thank you -Andrea-
Re: current best practice on the usage of the reject_unknown_hostname
Am 16.09.2014 um 23:24 schrieb AndreaML:
> Is it also your experience? Has reject_unknown_hostname less and less use in
> favour of other anti-spam methods?
>
> because in a server with 5000 mailbox and 80k-100k messages a day, that
> setting free me of 20k-30k spam messages easily, but catch these large
> institutions.
>
> i am just a bit confused. what is your experience on this?
that still too much mail admins sadly don't care about 3 things
* A record
* PTR
* HELO name
and instead "reject_unknown_hostname" you need for a sane sleep
specific rules to at least reject insane HELO :-(
smtpd_helo_restrictions =
permit_mynetworks
permit_sasl_authenticated
check_sender_access /etc/postfix/whitelist_sender.cf
check_helo_access regexp:/etc/postfix/blacklist_helo.cf
reject_non_fqdn_helo_hostname
reject_invalid_helo_hostname
_
/etc/postfix/blacklist_helo.cf:
/.*\.91\.118\.73\..*/
REJECT Unacceptable HELO
/^91\.118\.73\..*/
REJECT Unacceptable HELO
/^\[10\.0\..*/
REJECT Unacceptable HELO
/^10\.0\..*/
REJECT Unacceptable HELO
/^\[192\.168\..*/
REJECT Unacceptable HELO
/^192\.168\..*/
REJECT Unacceptable HELO
/.*\.administrator$/
REJECT Unacceptable HELO
/.*\.admin$/
REJECT Unacceptable HELO
/.*\.arpa$/
REJECT Unacceptable HELO
/.*\.dhcp$/
REJECT Unacceptable HELO
/.*\.dns$/
REJECT Unacceptable HELO
/.*\.dynamic$/
REJECT Unacceptable HELO
/.*\.dyn$/
REJECT Unacceptable HELO
/.*\.dyndns\.org$/
REJECT Unacceptable HELO
/.*\.gateway$/
REJECT Unacceptable HELO
/.*\.home$/
REJECT Unacceptable HELO
/.*\.internal$/
REJECT Unacceptable HELO
/.*\.intern$/
REJECT Unacceptable HELO
/.*\.lan$/
REJECT Unacceptable HELO
/.*\.localdomain$/
REJECT Unacceptable HELO
/.*\.localhost$/
REJECT Unacceptable HELO
/.*\.local$/
REJECT Unacceptable HELO
/.*\.lokal$/
REJECT Unacceptable HELO
/.*\.nat$/
REJECT Unacceptable HELO
/.*\.netzwerk$/
REJECT Unacceptable HELO
/.*\.pc$/
REJECT Unacceptable HELO
/.*\.privat$/
REJECT Unacceptable HELO
/.*\.private$/
REJECT Unacceptable HELO
/.*\.router$/
REJECT Unacceptable HELO
/^[0-9]{1,3}\-[0-9]{1,3}\-[0-9]{1,3}\-[0-9]{1,3}.*\.highway\.telekom\.at$/
REJECT Unacceptable HELO
/^[0-9]{1,3}\-[0-9]{1,3}\-[0-9]{1,3}\-[0-9]{1,3}\.dynamic\.surfer\.at$/
REJECT Unacceptable HELO
/^chello.*\.dynamic\.surfer\.at$/
REJECT Unacceptable HELO
/^chello.*\.graz\.surfer\.at$/
REJECT Unacceptable HELO
/^chello.*\.klafu\.surfer\.at$/
REJECT Unacceptable HELO
/^chello.*\.tirol\.surfer\.at$/
REJECT Unacceptable HELO
/^chello.*\.vie\.surfer\.at$/
REJECT Unacceptable HELO
/^chello.*\.wrn\.surfer\.at$/
REJECT Unacceptable HELO
/.*\.hinet\-ip\.hinet\.net$/
REJECT Unacceptable HELO
/.*\.dynamic\.hinet\.net$/
REJECT Unacceptable HELO
/.*\.dynamic\-ip\.hinet\.net$/
Re: FYI: blocking attachment extensions
MIMEDefang allows you to do all this, plus you can call Perl modules like File::Type on attachments to figure out if the file has been mistyped (i.e. the content-type disagrees with what the actual file header and/or file extension says it is). -Philip On Sep 16, 2014, at 12:04 PM, li...@rhsoft.net wrote: > (yes i know it's not 100% perfect in any case) > > but anybody using "mime_header_checks" by one of the similar howtos out > there should review the configuration - without \" at the end of the > regex this is prone to false positives > > two examples from real world (.scr and .com wrongly rejected) > > * name="strace.Scripting-with-the-xss.pdf.txt" > * filename="BOOKING.COM: Hotel 342802.PDF" > > i think this was the one i followed > http://www.cyberciti.biz/tips/postfix-block-mime-attachment-files.html > _ > > cat /etc/postfix/mime_header_checks.cf > # Reject Attachment-Extensions > /name=[^>]*\.(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|msc|msi|msp|mst|ocx|pcd|pif|pl|reg|scr|script|sct|sh|shb|shs|sys|so|tlb|vb|vbe|vbs|wiz|wll|wpc|wsc|wsf|wsh)\"/ > REJECT 554 Attachment Blocked > >
Re: FYI: blocking attachment extensions
Am 17.09.2014 um 00:18 schrieb Philip Prindeville: > MIMEDefang allows you to do all this, plus you can call Perl modules like > File::Type on attachments to figure out if the file has been mistyped (i.e. > the content-type disagrees with what the actual file header and/or file > extension says it is). thanks - but the idea is not to add another layer there are already clamav and spamassassin as milter the intention is to avoid the additional layers in case of bad extensions current question is why a "test.exe" attached by Thunderbird works fine with Viktors rule with postmap but not in real operations while it was made sure the config file is used adn all reloaded > On Sep 16, 2014, at 12:04 PM, li...@rhsoft.net wrote: > >> (yes i know it's not 100% perfect in any case) >> >> but anybody using "mime_header_checks" by one of the similar howtos out >> there should review the configuration - without \" at the end of the >> regex this is prone to false positives >> >> two examples from real world (.scr and .com wrongly rejected) >> >> * name="strace.Scripting-with-the-xss.pdf.txt" >> * filename="BOOKING.COM: Hotel 342802.PDF" >> >> i think this was the one i followed >> http://www.cyberciti.biz/tips/postfix-block-mime-attachment-files.html >> _ >> >> cat /etc/postfix/mime_header_checks.cf >> # Reject Attachment-Extensions >> /name=[^>]*\.(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|msc|msi|msp|mst|ocx|pcd|pif|pl|reg|scr|script|sct|sh|shb|shs|sys|so|tlb|vb|vbe|vbs|wiz|wll|wpc|wsc|wsf|wsh)\"/ >> REJECT 554 Attachment Blocked
RE: FYI: blocking attachment extensions
Here is my suggestion: The idea is simple, don't allow attachments that can be executed by network users and scan everything else (such as docs). For that, I use amavid-new with decoders, 7zip for .zip instead of the perl library used by amavisd-new (it fails on many .zip). I pretty much covered all file types and quarantined (not blocked) executables since ClamAV and another commercial AV missed few signatures (zero day protection may take 23 hours). With the help of header_check in Postfix I use a "passphrase" in subject in order to avoid the banning in amavis (redirect to a second amavis socket with a different policy map) whenever executables or encrypted files are needed to be sent in legit scenarios. Marius. -Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of li...@rhsoft.net Sent: Tuesday, September 16, 2014 9:38 PM To: postfix-users@postfix.org Subject: Re: FYI: blocking attachment extensions Am 16.09.2014 um 20:34 schrieb Wietse Venema: > li...@rhsoft.net: >> (yes i know it's not 100% perfect in any case) >> >> but anybody using "mime_header_checks" by one of the similar howtos >> out there should review the configuration - without \" at the end of >> the regex this is prone to false positives > > Caution: MIME allows names in this context without "", as long as > those names contain no whitespace etc. thanks for the hint i am open for suggestions how to optimize that in general without raise false positives - at the end there is clamd but "mime_header_checks" is "cheaper" >> two examples from real world (.scr and .com wrongly rejected) >> >> * name="strace.Scripting-with-the-xss.pdf.txt" >> * filename="BOOKING.COM: Hotel 342802.PDF" >> >> i think this was the one i followed >> http://www.cyberciti.biz/tips/postfix-block-mime-attachment-files.htm >> l _ >> >> cat /etc/postfix/mime_header_checks.cf >> # Reject Attachment-Extensions >> /name=[^>]*\.(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cnv|com|cpl| >> crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|msc|msi|msp|mst|o >> cx|pcd|pif|pl|reg|scr|script|sct|sh|shb|shs|sys|so|tlb|vb|vbe|vbs|wiz >> |wll|wpc|wsc|wsf|wsh)\"/ >> REJECT 554 Attachment Blocked
Re: current best practice on the usage of the reject_unknown_hostname
On 16 Sep 2014, at 15:24 , AndreaML wrote: > Sep 16 06:42:00 server1 postfix/smtpd[4257]: NOQUEUE: reject: RCPT from > wr001msr.fastwebnet.it[85.18.95.77]: 450 4.7.1 : Helo > command rejected: Host not found; from= to= > proto=ESMTP helo= > > for a transaction of a prefectly valid test email i sent to myself. Since your helo name does not exist, this is correct. I see very few rejections (relatively speaking) for non-existing domains or hosts. They are, definitionally, invalid emails. I haven’t looked closely, but I haven’t had anyone complain in quite a long time about missing mail. The there most recent are: 1E.bnsfd.com Nyt.pilisofe.com friendswhatitappears.in -- "An ounce of practice is worth more than tons of preaching." - Mohandas Gandhi
Re: FYI: blocking attachment extensions
li...@rhsoft.net: > >>> Content-Type: application/octet-stream; > >>> name="test.exe" To test multiline headers, use "postmap -h -q" Wietse
Re: FYI: blocking attachment extensions
On Tue, Sep 16, 2014 at 07:14:51PM -0400, Wietse Venema wrote: > li...@rhsoft.net: > > >>> Content-Type: application/octet-stream; > > >>> name="test.exe" > > To test multiline headers, use "postmap -h -q" That's of course with "postmap -h -q -" when reading messages (or message headers) from a file. When the header string is a command-line argument: postmap -q "...header data..." pcre:/some/path.pcre the "-h" option is not needed and not available. -- Viktor.
Re: FYI: blocking attachment extensions
Am 17.09.2014 um 01:19 schrieb Viktor Dukhovni: > On Tue, Sep 16, 2014 at 07:14:51PM -0400, Wietse Venema wrote: > >> li...@rhsoft.net: >> Content-Type: application/octet-stream; >> name="test.exe" >> >> To test multiline headers, use "postmap -h -q" > > That's of course with "postmap -h -q -" when reading messages (or > message headers) from a file. When the header string is a command-line > argument: > > postmap -q "...header data..." pcre:/some/path.pcre > > the "-h" option is not needed and not available i still don't understand why "postmap" has a result but with postfix Viktors rule don't catch the attachment and so finally my one from the initial posting two lines below triggers
Re: FYI: blocking attachment extensions
Viktor Dukhovni: > On Tue, Sep 16, 2014 at 07:14:51PM -0400, Wietse Venema wrote: > > > li...@rhsoft.net: > > > >>> Content-Type: application/octet-stream; > > > >>> name="test.exe" > > > > To test multiline headers, use "postmap -h -q" > > That's of course with "postmap -h -q -" when reading messages (or > message headers) from a file. When the header string is a command-line > argument: > > postmap -q "...header data..." pcre:/some/path.pcre > > the "-h" option is not needed and not available. Multi-line arguments have resulted in privilege escalation with Sendmail. I'm not fond of multi-line command-line arguments, and consider it sloppiness that postmap allows them. To simulate multiline input, one can feed into stdin. printf whatever | postmap -q - ... Wietse
Re: FYI: blocking attachment extensions
On Wed, Sep 17, 2014 at 01:24:27AM +0200, li...@rhsoft.net wrote: > I still don't understand why "postmap" has a result but with > postfix Viktors rule don't catch the attachment and so finally > my one from the initial posting two lines below triggers The live configuration must differ from the test configuration, or your test is flawed. Submit mail with sendmail(1): ( printf 'From: %s\n' "$(id -nu)" printf 'To: %s\n' "$(id -nu)" printf 'Subject: test %d\n' "$(date +%s)" printf 'MIME-Version: 1.0\n' printf 'Content-Type: application/octet-stream;\n' printf ' name=test.exe; charset=us-ascii\n' printf '\n' printf 'Hi there.\n' ) | /usr/sbin/sendmail -it Likewise: ( printf 'From: %s\n' "$(id -nu)" printf 'To: %s\n' "$(id -nu)" printf 'Subject: test %d\n' "$(date +%s)" printf 'MIME-Version: 1.0\n' printf 'Content-Type: application/octet-stream;\n' printf ' name=test.exe; charset=us-ascii\n' printf '\n' printf 'Hi there.\n' ) | postmap -h -q - $(postconf -hx mime_header_checks) Compare mail logs with command-line output. If not the same, something in your configuration is causing a different set of rules to be used. Perhaps you've multiple cleanup instances (different cleanup for submission). -- Viktor.
Re: FYI: blocking attachment extensions
> On 16 Sep 2014, at 13:00 , Viktor Dukhovni wrote: > > On Tue, Sep 16, 2014 at 01:41:36PM -0500, Noel Jones wrote: > >> I've used the below for a few years with good results. It's better, >> but surely not perfect. >> >> >> # block windows executables PCRE >> /^\s*Content-(Disposition|Type).*name\s*=\s*"?(.*(\.|=2E)( >> ade|adp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|hlp|hta| >> inf|ins|isp|js|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws| >> ops|pcd|pif|prf|reg|scf|scr|sct|shb|shs|shm|swf| >> vb|vbe|vbs|vbx|vxd|wsc|wsf|wsh))(\?=)?"?\s*$/x > > This assumes that "name" or "filename" is the last attribute in > the header. It might instead be followed by a ";" and more > attributes. So for a bit more generality, try the below: > ># block windows executables PCRE >/^\s*Content-(?:Disposition|Type): # Header label > (?:.*?;)? \s*# Any prior attributes > (?:file)?name\s*=\s*"? # name or filename > ( # Capture name for response >.*?(\.|=2E)# File basename and "." > (ade|adp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|hlp|hta| > inf|ins|isp|js|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws| > ops|pcd|pif|prf|reg|scf|scr|sct|shb|shs|shm|swf| > vb|vbe|vbs|vbx|vxd|wsc|wsf|wsh) # Capture risky extensions > ) # Close capture > (?:\?=)?# Trailer of ad-hoc RFC 2047 > encoding > "? # Optional close quote > \s*(;|$)# End of attribute or header > /x > > [ untested ] Hmm. I’ve been using the same check as Noel for many years. More than 10. I’ve never received an attachment in that list, so … -- The Earth is like a tiny grain of sand, only much, much heavier.
Re: FYI: blocking attachment extensions
Am 17.09.2014 um 01:42 schrieb Viktor Dukhovni: > On Wed, Sep 17, 2014 at 01:24:27AM +0200, li...@rhsoft.net wrote: > >> I still don't understand why "postmap" has a result but with >> postfix Viktors rule don't catch the attachment and so finally >> my one from the initial posting two lines below triggers > > The live configuration must differ from the test configuration, or > your test is flawed. you may not believe it but there is no live / test - just one configuration the "test" is just send a mail with Thunderbird and a example attachment, in the case below a zerobyte file named "test.exe.txt.sh", added to a new message with subject and body test > Compare mail logs with command-line output. If not the same, > something in your configuration is causing a different set of rules > to be used. Perhaps you've multiple cleanup instances (different > cleanup for submission) for sure not - there is no submission - just Port 25 and the config file is used because it reflects comment out rules and do the same test after reload postfix that was the reason to add (Rule XX) to the reject message __ that is the log: Sep 17 01:53:57 mail-gw postfix/cleanup[28448]: 3hyLr521BVz1l: reject: header Content-Type: application/x-shellscript;? name="test.exe.txt.sh" from **; from= to=<> proto=ESMTP helo=: 5.7.1 554 Attachment Blocked (Rule 4) __ that is the content of the config - the config is used 100% for sure because befor the hitting rule had (Rule 3) and yours was on top with (Rule 0) now renumbered tu (Rule 1) [root@mail-gw:~]$ cat postfix/mime_header_checks.cf # Reject Attachment Extensions /^Content-(?:Disposition|Type):(?:.*?;)? \s*(?:file)?name \s* = \s*"?(.*?(\.|=2E)(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cmd|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|ocx|ops|pcd|pif|pl|prf|reg|scf|scr|script|sct|sh|shb|shm|shs|so|sys|tlb|vb|vbe|vbs|vbx|vxd|wiz|wll|wpc|wsc|wsf|wsh))(?:\?=)?"?\s*(;|$)/x REJECT 554 Attachment Blocked (Rule 1) /^\s*Content-(Disposition|Type).*name\s*=\s*"?(.*(\.|=2E)(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cmd|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|ocx|ops|pcd|pif|pl|prf|reg|scf|scr|script|sct|sh|shb|shm|shs|so|sys|tlb|vb|vbe|vbs|vbx|vxd|wiz|wll|wpc|wsc|wsf|wsh))(\?=)?"?\s*$/x REJECT 554 Attachment Blocked (Rule 2) /^\s*Content-(?:Disposition|Type):(?:.*?;)?\s*(?:file)?name\s*=\s*"?(.*?(\.|=2E)(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cmd|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|ocx|ops|pcd|pif|pl|prf|reg|scf|scr|script|sct|sh|shb|shm|shs|so|sys|tlb|vb|vbe|vbs|vbx|vxd|wiz|wll|wpc|wsc|wsf|wsh))(?:\?=)?"?\s*(;|$)/x REJECT 554 Attachment Blocked (Rule 3) /name=[^>]*\.(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cmd|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|ocx|ops|pcd|pif|pl|prf|reg|scf|scr|script|sct|sh|shb|shm|shs|so|sys|tlb|vb|vbe|vbs|vbx|vxd|wiz|wll|wpc|wsc|wsf|wsh)\"/ REJECT 554 Attachment Blocked (Rule 4)
Re: current best practice on the usage of the reject_unknown_hostname
On 16 Sep 2014, at 17:24, AndreaML wrote: hello all, I am used to have in the config reject_unknown_hostname in the smtpd_helo_restrictions and for literally years my mailserver were good. You were lucky. That setting (in modern Postfix 'reject_unknown_helo_hostname') has never been safe. BUT in the last months, say from the start of the year i am rejecting more and more messages from reliable sources as the mail servers of pieces of italian government and some very big ISPs like FastWeb. This is not a universal trend, it is a quirk of your particular mailstream and/or environment. Otherwise legitimate MTA's have been using variously bogus HELO/EHLO names for all of the past 23 years and probably for all of the history of SMTP. One factor which MAY be increasing the appearance of more failures is the gradual migration towards IPv6. It is increasingly common for DNS resolvers to support IPv6 by default and run on machines where IPv6 is enabled but where there is no (or limited) IPv6 connectivity. This can cause a resolver to query IPv6 NS addresses that it can't actually reach, potentially resulting in resolution failures. My log files are filled with (example) Sep 16 06:42:00 server1 postfix/smtpd[4257]: NOQUEUE: reject: RCPT from wr001msr.fastwebnet.it[85.18.95.77]: 450 4.7.1 : Helo command rejected: Host not found; from= to= proto=ESMTP helo= for a transaction of a prefectly valid test email i sent to myself. More and more i see large installations with EHLOs to some local intranet names and thus not resolvable host names in dns provoking the reject in my postfix. Is it also your experience? Has reject_unknown_hostname less and less use in favour of other anti-spam methods? I am unaware of it ever being widely used. Note that RFC2821 S4.1.4 explicitly states: An SMTP server MAY verify that the domain name parameter in the EHLO command actually corresponds to the IP address of the client. However, the server MUST NOT refuse to accept a message for this reason if the verification fails: the information about verification failure is for logging and tracing only. This is essentially a restatement of RFC1123 S5.2.5 and was retained in RFC5321. Of course RFCs are not laws & one is free to do whatever one feels like doing in deciding how to determine whether or not to accept mail, but for 25 years the RFCs have been vehemently discouraging verification of the HELO/EHLO argument *because* it has always been well-known that such verification often fails for mail that is otherwise entirely legitimate. It is much safer to use 'reject_invalid_helo_hostname' or 'reject_non_fqdn_helo_hostname' or for maximal safety to use a 'check_helo_access' map to specifically reject HELO names & patterns that fingerprint spambots (e.g. 'friend', 'ylmf-pc', '[127.0.0.1]', your own local names/IPs, etc.) or gross incompetence (unqualified names, *.local, etc.) and perhaps to exempt special cases where you are willing to tolerate incompetence. because in a server with 5000 mailbox and 80k-100k messages a day, that setting free me of 20k-30k spam messages easily, but catch these large institutions. i am just a bit confused. what is your experience on this? I've never used that option with Postfix or any analogous setting in other MTAs, but I have looked at it as a possibility a few times. When I last examined it in depth (2007, at a site getting ~10E6 SMTP sessions per day, because one IT manager had one spam with a bad HELO) the overwhelming majority (>98%) of SMTP clients using unresolvable HELO names that were not known sources of legitimate mail were also identifiable as undesirable by some other mechanism before DATA (which included a set of telltale HELO patterns.) It simply didn't matter that we were not rejecting unresolvable HELO names, because the *marginal* effect of doing so would have been many more more false positives than additional actual spam being caught. There are a lot of reasons that may not reflect your system today but the important point that does is that you should focus on the net marginal effect of that option instead of the raw fact that it catches a huge pile of probable spam very early.
Re: FYI: blocking attachment extensions
*argh* "regexp" versus "pcre" i only replaced the regex without realite the different map type that's why i posted "postconf -n" :-( however, works now, thank you! Am 17.09.2014 um 01:59 schrieb li...@rhsoft.net: > Am 17.09.2014 um 01:42 schrieb Viktor Dukhovni: >> On Wed, Sep 17, 2014 at 01:24:27AM +0200, li...@rhsoft.net wrote: >> >>> I still don't understand why "postmap" has a result but with >>> postfix Viktors rule don't catch the attachment and so finally >>> my one from the initial posting two lines below triggers >> >> The live configuration must differ from the test configuration, or >> your test is flawed. > > you may not believe it but > > there is no live / test - just one configuration > > the "test" is just send a mail with Thunderbird and a example attachment, > in the case below a zerobyte file named "test.exe.txt.sh", added to a new > message with subject and body test > >> Compare mail logs with command-line output. If not the same, >> something in your configuration is causing a different set of rules >> to be used. Perhaps you've multiple cleanup instances (different >> cleanup for submission) > > for sure not - there is no submission - just Port 25 and the > config file is used because it reflects comment out rules > and do the same test after reload postfix > > that was the reason to add (Rule XX) to the reject message > __ > > that is the log: > > Sep 17 01:53:57 mail-gw postfix/cleanup[28448]: 3hyLr521BVz1l: reject: header > Content-Type: > application/x-shellscript;? name="test.exe.txt.sh" from **; > from= to=<> > proto=ESMTP helo=: 5.7.1 554 Attachment Blocked (Rule > 4) > __ > > that is the content of the config - the config is used 100% for sure > because befor the hitting rule had (Rule 3) and yours was on top with > (Rule 0) now renumbered tu (Rule 1) > > [root@mail-gw:~]$ cat postfix/mime_header_checks.cf > # Reject Attachment Extensions > > /^Content-(?:Disposition|Type):(?:.*?;)? \s*(?:file)?name \s* = > \s*"?(.*?(\.|=2E)(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cmd|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|ocx|ops|pcd|pif|pl|prf|reg|scf|scr|script|sct|sh|shb|shm|shs|so|sys|tlb|vb|vbe|vbs|vbx|vxd|wiz|wll|wpc|wsc|wsf|wsh))(?:\?=)?"?\s*(;|$)/x > REJECT 554 Attachment Blocked (Rule 1) > > /^\s*Content-(Disposition|Type).*name\s*=\s*"?(.*(\.|=2E)(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cmd|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|ocx|ops|pcd|pif|pl|prf|reg|scf|scr|script|sct|sh|shb|shm|shs|so|sys|tlb|vb|vbe|vbs|vbx|vxd|wiz|wll|wpc|wsc|wsf|wsh))(\?=)?"?\s*$/x > REJECT 554 Attachment Blocked (Rule 2) > > /^\s*Content-(?:Disposition|Type):(?:.*?;)?\s*(?:file)?name\s*=\s*"?(.*?(\.|=2E)(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cmd|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|ocx|ops|pcd|pif|pl|prf|reg|scf|scr|script|sct|sh|shb|shm|shs|so|sys|tlb|vb|vbe|vbs|vbx|vxd|wiz|wll|wpc|wsc|wsf|wsh))(?:\?=)?"?\s*(;|$)/x > REJECT 554 Attachment Blocked (Rule 3) > > /name=[^>]*\.(386|acm|ade|adp|awx|ax|bas|bat|bin|cdf|chm|cmd|cnv|com|cpl|crt|csh|dll|dlo|drv|exe|hlp|hta|inf|ins|isp|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|ocx|ops|pcd|pif|pl|prf|reg|scf|scr|script|sct|sh|shb|shm|shs|so|sys|tlb|vb|vbe|vbs|vbx|vxd|wiz|wll|wpc|wsc|wsf|wsh)\"/ > REJECT 554 Attachment Blocked (Rule 4)
