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 >>> (?

Re: postscreen deep protocol tests and Amazon timeouts

On Mon, Sep 15, 2014 at 10:24 PM, Wietse Venema wrote: > When you follow the include: directives you get lists of net/mask > forms that are easy to convert to postscreen. > > $ host -t txt spf1.amazon.com | tr ' ' '\12' | sed -n '/^ip.:/{ > s/^ip.:\(.*\)/\1 permit/ > p > }'

Reverse DNS Failure Code

There's an RFC for "Email Authentication Status Codes" out, which specifies a dedicated status code "when an SMTP client's IP address failed a reverse DNS validation check, contrary to local policy requirements" (see: 3.3. Reverse DNS Failure Code): 3.

Re: FYI: blocking attachment extensions

Am 17.09.2014 um 10:02 schrieb Christian Rößner : > /xREJECT blocked filename ${1} Missing indention here. Got it. Thanks Christian -- Bachelor of Science Informatik Erlenwiese 14, 36304 Alsfeld T: +49 6631 78823400, F: +49 6631 78823409, M: +49 171 9905345 USt-IdNr.: DE225

Re: FYI: blocking attachment extensions

Am 17.09.2014 um 11:28 schrieb Christian Rößner: > Am 17.09.2014 um 10:02 schrieb Christian Rößner > : > >> /x REJECT blocked filename ${1} > > Missing indention here. Got it. Thanks i attached once again my final (appearing to work) config file - may somebody review if there

Re: current best practice on the usage of the reject_unknown_hostname

On Tuesday 16 September 2014 23:33:43 li...@rhsoft.net wrote: > > 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 :-( > thank

Re: current best practice on the usage of the reject_unknown_hostname

On Wednesday 17 September 2014 00:31:48 LuKreme wrote: > 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

Re: current best practice on the usage of the reject_unknown_hostname

Am 17.09.2014 um 11:37 schrieb AndreaML: > On Tuesday 16 September 2014 23:33:43 li...@rhsoft.net wrote: >> >> 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

Re: current best practice on the usage of the reject_unknown_hostname

On 16 Sep 2014, at 17:59 , Bill Cole wrote: > 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',

can check_helo_access go in smtpd_helo_restrictions?

Subject kind of says it all, can you put check_helo_access in the smtpd_helo_restrictions block or does it need to be in smtp_recipient_restrictions? -- Good old Dame Fortune. You can _depend_ on her.

Re: can check_helo_access go in smtpd_helo_restrictions?

Am 17.09.2014 um 12:17 schrieb LuKreme: > Subject kind of says it all, can you put check_helo_access in the > smtpd_helo_restrictions block or does it need to be in > smtp_recipient_restrictions? yes, it's indicated by the name but anyways: http://www.postfix.org/postconf.5.html#smtpd_delay_rej

Re: can check_helo_access go in smtpd_helo_restrictions?

Am 17.09.2014 um 12:17 schrieb LuKreme: > Subject kind of says it all, can you put check_helo_access in the > smtpd_helo_restrictions block or does it need to be in > smtp_recipient_restrictions? > i have smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authen

Re: FYI: blocking attachment extensions

li...@rhsoft.net: > /^Content-(?:Disposition|Type):stuff/x REJECT 554 Attachment Blocked "$1" - What is $1 supposed to contain? - Use "REJECT" or "554", not both. Wietse

Re: postscreen deep protocol tests and Amazon timeouts

Jose Borges Ferreira: > On Mon, Sep 15, 2014 at 10:24 PM, Wietse Venema wrote: > > When you follow the include: directives you get lists of net/mask > > forms that are easy to convert to postscreen. > > > > $ host -t txt spf1.amazon.com | tr ' ' '\12' | sed -n '/^ip.:/{ > > s/^ip.:\(.*

Re: FYI: blocking attachment extensions

Am 17.09.2014 um 13:20 schrieb Wietse Venema: > li...@rhsoft.net: >> /^Content-(?:Disposition|Type):stuff/x REJECT 554 Attachment Blocked "$1" > > - What is $1 supposed to contain? in fact the attachment name in the log as well as in the REJET response (Thunderbird dialog) excerpt from the logs

Re: Reverse DNS Failure Code

Patrick Ben Koetter: > There's an RFC for "Email Authentication Status Codes" > out, which specifies a dedicated > status code "when an SMTP client's IP address failed a reverse DNS validation > check, contrary to local policy requirements" (see: 3.3. R

Re: Reverse DNS Failure Code

* Wietse Venema : > Patrick Ben Koetter: > > There's an RFC for "Email Authentication Status Codes" > > out, which specifies a > > dedicated > > status code "when an SMTP client's IP address failed a reverse DNS > > validation > > check, contrary to lo

Re: Reverse DNS Failure Code

On Wed, Sep 17, 2014 at 03:09:15PM +0200, Patrick Ben Koetter wrote: > > Thanks for keeping an eye on this. Yes, I suppose that Postfix > > should adopt such status codes (make them configurable?), but there > > is no need to do this for older releases. > > Having them configurable with sane defa

Re: different transport for all mail introduced via sendmail(1)

On 2014.09.10 14.02, wie...@porcupine.org (Wietse Venema) wrote: > btb: >> hi- >> >> i have a mail submission server [submission/587 only] [msa.example.com] >> for our users [config below]. in that context, it's working as desired. >>we also have another, separate, msa [msa.systems.example.com

smtp-sink: fatal: sockaddr_to_hostaddr: Non-recoverable failure in name resolution

Was investigating why I can't connect to my smtp-sink: $ smtp-sink -v [::1]:10055 10 smtp-sink: name_mask: all smtp-sink: trying... [::1]:10055 then in another window: $ smtp-source [::1]:10055 and the smtp-sink aborts with: smtp-sink: fatal: sockaddr_to_hostaddr: Non-recoverable failure i

Re: smtp-sink: fatal: sockaddr_to_hostaddr: Non-recoverable failure in name resolution

Mark Martinec: > Turns out that the problem is a structure declared too short > by two bytes to receive a sockaddr_in6 from accept(), > and the two bytes of a received IP address are then clobbered. > > In smtp-sink.c/connect_event() the sa is declared > as struct sockaddr instead of struct sockad

Re: smtp-sink: fatal: sockaddr_to_hostaddr: Non-recoverable failure in name resolution

On Wed, Sep 17, 2014 at 06:48:28PM +0200, Mark Martinec wrote: > Was investigating why I can't connect to my smtp-sink: > > $ smtp-sink -v [::1]:10055 10 > smtp-sink: name_mask: all > smtp-sink: trying... [::1]:10055 > > then in another window: $ smtp-source [::1]:10055 > > and the smtp-sin

Re: smtp-sink: fatal: sockaddr_to_hostaddr: Non-recoverable failure in name resolution

Viktor Dukhovni: > I gather you're suggesting a chang along the lines of: > > diff --git a/src/smtpstone/smtp-sink.c b/src/smtpstone/smtp-sink.c > index 617fbf9..33872b0 100644 I came up with similar code. It works without surprises. Wietse

Dealing with a lookup with null result?

Quick question… I finally decided to build a web UI for our support guys to be able to manually kill relaying for compromised accounts using the new check_sasl_access (http://www.postfix.org/postconf.5.html#check_sasl_access) feature introduced in 2.11. A thread regarding this is here: htt

Re: Dealing with a lookup with null result?

>CSS: > Quick question? > > I finally decided to build a web UI for our support guys to be > able to manually kill relaying for compromised accounts using the > new check_sasl_access > (http://www.postfix.org/postconf.5.html#check_sasl_access) feature > introduced in 2.11. > > A thread regarding th

Re: tlsv1 alert decode error

On Mon, Sep 15, 2014 at 04:59:15PM +1000, shm...@riseup.net wrote: > This server is using an EC cert not RSA eventually, The email gets sent > in the clear any help appreciated. The above is devoid of any technical content. No help is possible. http://www.postfix.org/DEBUG_README.html#mail

Re: blocking attachment extensions

On 16 Sep 2014, at 18:18, Philip Prindeville wrote: 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

Re: Dealing with a lookup with null result?

On Sep 17, 2014, at 2:19 PM, Wietse Venema wrote: >> CSS: >> Quick question? >> >> I finally decided to build a web UI for our support guys to be >> able to manually kill relaying for compromised accounts using the >> new check_sasl_access >> (http://www.postfix.org/postconf.5.html#check_sasl_ac

Re: Dealing with a lookup with null result?

CSS: > I often get confused about the difference between responses from > a policy check and an access check. I guess they are basically > the same. There is no difference. As documented in SMTPD_POLICY_README: The policy server replies with any action that is allowed in a Postfix SMTPD

Re: blocking attachment extensions

On Sep 17, 2014, at 3:28 PM, Bill Cole wrote: > On 16 Sep 2014, at 18:18, Philip Prindeville wrote: > >> 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