Re: patch: mitigate CRIME attack

Andreas Schiermeier wrote: >I'm confident our auditors will understand and accept the >argumentation. >The finding comes from an automated scan. > >It's good to know 2.11 will include the ability to disable compression. > >Maybe I'll inform Ubuntu package maintainers about my patch, in case >th

Re: Restrictions after postscreen

On 5/14/2013 11:45 AM, Steve Jenkins wrote: > On Tue, May 14, 2013 at 8:33 AM, /dev/rob0 wrote: > >> On Tue, May 14, 2013 at 07:49:50AM -0700, Steve Jenkins wrote: >>> smtpd_recipient_restrictions = >>> reject_invalid_helo_hostname, >>> warn_if_reject reject_non_fqdn_helo_hostname

Re: HOLDing certain recipients during migration

On Tue, May 14, 2013 at 10:37 AM, francis picabia wrote: > > On Tue, Feb 19, 2013 at 9:20 PM, Sahil Tandon > wrote: >> >> On Thu, 2013-02-14 at 13:13:54 +0100, Miha Valencic wrote: >> >> > On Thu, Feb 14, 2013 at 1:01 PM, Noel Jones wrote: >> > > HOLD acts at the message level, not the recipien

Re: Restrictions after postscreen

On Tue, May 14, 2013 at 8:33 AM, /dev/rob0 wrote: > On Tue, May 14, 2013 at 07:49:50AM -0700, Steve Jenkins wrote: > > smtpd_recipient_restrictions = > > reject_invalid_helo_hostname, > > warn_if_reject reject_non_fqdn_helo_hostname, > > reject_unknown_reverse_client_hostn

Re: Restrictions after postscreen

On Tue, May 14, 2013 at 07:49:50AM -0700, Steve Jenkins wrote: > smtpd_recipient_restrictions = > reject_invalid_helo_hostname, > warn_if_reject reject_non_fqdn_helo_hostname, > reject_unknown_reverse_client_hostname, > warn_if_reject reject_unknown_helo_hostname, >

Re: patch: mitigate CRIME attack

I'm confident our auditors will understand and accept the argumentation. The finding comes from an automated scan. It's good to know 2.11 will include the ability to disable compression. Maybe I'll inform Ubuntu package maintainers about my patch, in case there is rising demand for jumping throug

Re: Restrictions after postscreen

On Mon, May 13, 2013 at 6:42 PM, Noel Jones wrote: > Don't forget that all the other main.cf parameters are still in > effect on your "submission" entry; likely you're seeing unintended > spillover. > > I suggest setting ALL the smtpd_*_restrictions entries for > submission in master.cf so you do

Re: Restrictions after postscreen

On Tue, May 14, 2013 at 7:38 AM, Charles Marcus wrote: > On 2013-05-14 10:35 AM, Steve Jenkins wrote: > >> >> # postconf -d | grep smtpd_relay >> smtpd_relay_restrictions = permit_mynetworks, reject_unauth_destination >> >> Any idea why my permit_sasl_authenticated is being ignored in favor of >>

Re: Restrictions after postscreen

On Tue, May 14, 2013 at 07:35:15AM -0700, Steve Jenkins wrote: > # postconf -d | grep smtpd_relay > smtpd_relay_restrictions = permit_mynetworks, reject_unauth_destination > Any idea why my permit_sasl_authenticated is being ignored in favor of the > default? | -d Print main.cf default parameter

Re: Restrictions after postscreen

On 2013-05-14 10:35 AM, Steve Jenkins wrote: # postconf -d | grep smtpd_relay smtpd_relay_restrictions = permit_mynetworks, reject_unauth_destination Any idea why my permit_sasl_authenticated is being ignored in favor of the default? -d gives DEFAULTS -n is what you want to use to see your

Re: Restrictions after postscreen

On Mon, May 13, 2013 at 6:42 PM, Noel Jones wrote: > On 5/13/2013 6:34 PM, Steve Jenkins wrote: > > On Wed, May 1, 2013 at 5:14 AM, /dev/rob0 > > wrote: > > > > > > > > Here are my current entries: > > > > > > smtpd_recipient_restrictions = > > >

Re: patch: mitigate CRIME attack

On Tue, May 14, 2013 at 02:03:44PM +0200, Andreas Schiermeier wrote: > Thank you Wietse and Viktor for your clarifications. > > I admit, there's absolutely no need for the patch past Postfix 2.8 with > OpenSSL 1.x. The SSL_OP_NO_COMPRESSION control is not part of SSL_OP_ALL (bug-interop work-aro

Re: HOLDing certain recipients during migration

On Tue, Feb 19, 2013 at 9:20 PM, Sahil Tandon wrote: > On Thu, 2013-02-14 at 13:13:54 +0100, Miha Valencic wrote: > > > On Thu, Feb 14, 2013 at 1:01 PM, Noel Jones > wrote: > > > HOLD acts at the message level, not the recipient level. > > > If one recipient of a multi-recipient message is put on

Re: postscreen and Google

On Tue, May 14, 2013 at 12:00:00AM -0600, LuKreme wrote: > /dev/rob0 opined on Monday 13-May-2013@06:06:27 > > All the Google, Facebook, Yahoo, et c. outbounds as well as > > most ISPs and legitimate bulk mailers are listed in the > > dnswl.org whitelist. Your best choice is to upgrade to > > post

Re: patch: mitigate CRIME attack

Thank you Wietse and Viktor for your clarifications. I admit, there's absolutely no need for the patch past Postfix 2.8 with OpenSSL 1.x. Andreas

Re: patch: mitigate CRIME attack

On 05/14/2013 05:05 PM, Viktor Dukhovni wrote: Don't listen to brainless auditors wielding checklists. Unfortunately you have to. They may be wrong but you're not going to pass PCI compliance scans unless you jump through their stupid hoops. I recommend that you don't put your MTA on the sa

Re: smtp_fallback_relay question

Ralf Hildebrandt: > If a SMTP destination is unreachable, is the smtp_fallback_relay tried > IMMEDATELY after not reaching the "real" destination or is the mail > being deferred and thus subject to queue_run_delay / minimal_backoff_time? Immediately. It is implemented as if there was an extra MX r

smtp_fallback_relay question

If a SMTP destination is unreachable, is the smtp_fallback_relay tried IMMEDATELY after not reaching the "real" destination or is the mail being deferred and thus subject to queue_run_delay / minimal_backoff_time? -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 M