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?

-- 
[*] 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, Axel von der Ohe, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

Re: smtp_fallback_relay question

[Wietse Venema]

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 record.

Wietse

Re: patch: mitigate CRIME attack

[Peter]

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 same server that you run 
your ecommerce apps on anyways, then you don't have to worry about 
passing PCI scans on the MTA.


As for this particular issue, I believe you can work around it to the 
satisfaction of the auditors by disabling any CBC ciphers.  You can use 
the command, "openssl ciphers" for a list, and then set 
smtpd_tls_exclude_ciphers to any that have CBC in the name.  No need to 
worry about smtp ciphers as the scanner can't detect those anyways.



Peter

Re: patch: mitigate CRIME attack

[Andreas Schiermeier]

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: postscreen and Google

[/dev/rob0]

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 
> > postfix-2.11-20130512 and use the new feature (see Wietse's 
> > thread about it yesterday.)
> 
> Thanks! That sounds very promising.

So far so good, here; now running the revised snapshot 
postfix-2.11-20130513. Mail (and spam) from Google gets through 
postscreen as soon as the DNS[BW]L score is computed. Not just 
Google: I have lots of others with a dnswl.org hit and "PASS NEW".

> I was hoping I could do something to pass *.google.com instead
> of the cidr map, but this sounds like it will be better.

This is not possible because postscreen does not look up a client's 
reverse DNS.
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: HOLDing certain recipients during migration

[francis picabia]

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 HOLD, all
> > > recipients of that message will be affected.
> >
> > I see. I believe the HOLD is better suited to our scenario as a
> > temporary reject and this (HOLDing messages for all recipients if one
> > matches) is acceptable.
>
> I do not understand your response; the HOLD action is not a temporary
> reject.  Anyway, my involvement earlier in the thread is for others who
> might chance upon this chain in the archives, and prefer the alternative
> (and IMHO more robust) approach.
>
>
Hello,

I looked up the other thread where it is suggested to use transport_maps
file with entry like:

u...@example.com retry:4.0.0 Mailbox being migrated

I've tested it, and it works fine if I use the target address
of virtual_alias_maps,
but not if I list the address in the email.  In our case this is to
hold/suspend email
until the mailbox is copied to a second system, where we continue to
run mail on both mailbox systems.

If I set up entries like:

u...@server1.example.com retry:4.0.0 Mailbox being migrated

That will keep it in the queue all right, but how to release it so it
will deliver to u...@server2.example.com after mailboxes have
been moved?  I'd think we'd need a way to hold it prior to getting
processed by the virtual mapping.

Re: patch: mitigate CRIME attack

[Viktor Dukhovni]

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-arounds enabled by default).  Therefore, there
is nothing in new releases of either OpenSSL or Postfix to disable
compression.

What Postfix 2.8 provides is the ability to turn off some work-arounds,
which has no effect on compression (and thus "CRIME").  Before 2.8,
all work-arounds were enabled.  Since your auditors want you to
jump through hoops (for no reason) to disable compression, if you
in fact must do this, just disable TLS support in Postfix, then
SSL compression is no longer on their checklist.

Turning off CBC ciphers while leaving TLS enabled will just create
a bunch of pain, as some sites turn off RC4 (which has its own
flaws) and TLSv1.2 modes are still not universally supported.

So your patch may apply to your site.  When I supported OpenSSL
a few years back at my previous employer (we built from source),
I always disabled compression at compile time (it never seemed
like a good idea to me, and my uninformed bias was vindicated).
That's another option.

Better than all of these is to talk to the auditor and explain
that SMTP != HTTP, and CRIME is an attack on HTTP + SSL, not
SMTP + SSL.  SMTP with compression, then SSL is far more secure
than SMTP with no SSL at all, which they would not even notice,
since most email is still not encrypted.  Some auditors can be
made to succumb to basic logic.

-- 
Viktor.

Re: Restrictions after postscreen

[Steve Jenkins]

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 =
> > > permit_mynetworks,
> > > permit_sasl_authenticated,
> >
> > I don't put these permit_* in global restrictions; I only apply them
> > to submission via -o smtpd_relay_restrictions=... in master.cf
> > . And
> > that brings up another point: if you're using 2.10 you now have
> > smtpd_relay_restrictions for relay control.
> >
> >
> > First, thanks for the extremely insightful help, Rob.
> >
> > OK - I commented those two lines out of smtpd_recipient_restrictions
> > as recommended, and added a new smtpd_relay_restrictions -o line to
> > submission in master.cf . My submission now reads:
> >
> > submission inet n   -   n   -   -   smtpd
> >   -o smtpd_tls_security_level=encrypt
> >   -o smtpd_sasl_auth_enable=yes
> >   -o smtpd_client_restrictions=permit_sasl_authenticated,reject
> >   -o milter_macro_daemon_name=ORIGINATING
> >   -o
> >
> smtpd_relay_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination
> >
> > However, I get this when sending a message from my home desktop
> > (connected via Comcast) via my personal Postfix server to my Gmail
> > test address:
>
> 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 don't have unexpected results.
>
> submission inet n   -   n   -   -   smtpd
>   -o smtpd_tls_security_level=encrypt
>   -o smtpd_sasl_auth_enable=yes
>   -o milter_macro_daemon_name=ORIGINATING
>   -o smtpd_client_restrictions=
>   -o smtpd_helo_restrictions=
>   -o smtpd_sender_restrictions=
>   -o smtpd_recipient_restrictions=
>   -o smtpd_relay_restrictions=permit_sasl_authenticated,reject


Hmm.. for some reason, I can't seem to get it to aceept my
smtpd_relay_restrictions settings.

In main.cf: smtpd_relay_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination

but the I get:

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

SteveJ

Re: Restrictions after postscreen

[Charles Marcus]

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 changes...

--

Best regards,

Charles

Re: Restrictions after postscreen

[Bastian Blank]

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 settings instead of actual settings.

Bastian

-- 
Four thousand throats may be cut in one night by a running man.
-- Klingon Soldier, "Day of the Dove", stardate unknown

Re: Restrictions after postscreen

[Steve Jenkins]

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
>> the default?
>>
>
> -d gives DEFAULTS
>
> -n is what you want to use to see your changes...
>

Doh. Of course it is. Can you tell I just woke up? :)

Re: Restrictions after postscreen

[Steve Jenkins]

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 don't have unexpected results.
>
> submission inet n   -   n   -   -   smtpd
>   -o smtpd_tls_security_level=encrypt
>   -o smtpd_sasl_auth_enable=yes
>   -o milter_macro_daemon_name=ORIGINATING
>   -o smtpd_client_restrictions=
>   -o smtpd_helo_restrictions=
>   -o smtpd_sender_restrictions=
>   -o smtpd_recipient_restrictions=
>   -o smtpd_relay_restrictions=permit_sasl_authenticated,reject


That was the final piece, Noel. Thx. Explicitly setting empty values for
those options for submission fixed whatever unintended spillover I was
experiencing.

Thanks to everyone's help here, I now have a slightly better understanding
of how these restrictions should work, and a much cleaner and easier to
understand list of recipient restrictions:

main.cf:

...
# SMTPD Restrictions
smtpd_helo_required = yes
disable_vrfy_command = yes

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,
check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre,
check_helo_access hash:/etc/postfix/helo_access,
check_sender_access hash:/etc/postfix/sender_access,
reject_rbl_client zen.spamhaus.org,
reject_rhsbl_client dbl.spamhaus.org,
reject_rhsbl_sender dbl.spamhaus.org,
reject_rhsbl_helo dbl.spamhaus.org,
permit_dnswl_client list.dnswl.org=127.0.[0..255].[1..3],
permit

smtpd_relay_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination

smtpd_data_restrictions = reject_unauth_pipelining
...

master.cf:
...
submission inet n   -   n   -   -   smtpd
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o milter_macro_daemon_name=ORIGINATING
  -o smtpd_client_restrictions=
  -o smtpd_helo_restrictions=
  -o smtpd_sender_restrictions=
  -o smtpd_recipient_restrictions=
  -o
smtpd_relay_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
  -o smtpd_data_restrictions=
  -o smtpd_end_of_data_restrictions=
...

Thanks again!

SteveJ

Re: patch: mitigate CRIME attack

[Andreas Schiermeier]

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 through "stupid hoops" :-).

Regards,
Andreas

Re: Restrictions after postscreen

[/dev/rob0]

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,
> check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre,
> check_helo_access hash:/etc/postfix/helo_access,
> check_sender_access hash:/etc/postfix/sender_access,
> reject_rbl_client zen.spamhaus.org,
> reject_rhsbl_client dbl.spamhaus.org,
> reject_rhsbl_sender dbl.spamhaus.org,
> reject_rhsbl_helo dbl.spamhaus.org,
> permit_dnswl_client list.dnswl.org=127.0.[0..255].[1..3],
> permit

The last two lines are no-op. If you have anything you want to be 
subjected to the list.dnswl.org whitelist, put it after the 
permit_dnswl_client. If not, there is no point in querying it.
-- 
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

Re: Restrictions after postscreen

[Steve Jenkins]

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_hostname,
> > warn_if_reject reject_unknown_helo_hostname,
> > check_reverse_client_hostname_access
> pcre:/etc/postfix/fqrdns.pcre,
> > check_helo_access hash:/etc/postfix/helo_access,
> > check_sender_access hash:/etc/postfix/sender_access,
> > reject_rbl_client zen.spamhaus.org,
> > reject_rhsbl_client dbl.spamhaus.org,
> > reject_rhsbl_sender dbl.spamhaus.org,
> > reject_rhsbl_helo dbl.spamhaus.org,
> > permit_dnswl_client list.dnswl.org=127.0.[0..255].[1..3],
> > permit
>
> The last two lines are no-op. If you have anything you want to be
> subjected to the list.dnswl.org whitelist, put it after the
> permit_dnswl_client. If not, there is no point in querying it.


Excellent point. If the next step is going to "permit" anyway, then no use
in the extra query. I've moved the dnswl.org line up so that it's just
above the three "local" check_* lines.

SteveJ

Re: HOLDing certain recipients during migration

[francis picabia]

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 recipient level.
>> > > If one recipient of a multi-recipient message is put on HOLD, all
>> > > recipients of that message will be affected.
>> >
>> > I see. I believe the HOLD is better suited to our scenario as a
>> > temporary reject and this (HOLDing messages for all recipients if one
>> > matches) is acceptable.
>>
>> I do not understand your response; the HOLD action is not a temporary
>> reject.  Anyway, my involvement earlier in the thread is for others who
>> might chance upon this chain in the archives, and prefer the alternative
>> (and IMHO more robust) approach.
>>
>
> Hello,
>
> I looked up the other thread where it is suggested to use transport_maps
> file with entry like:
>
> u...@example.com retry:4.0.0 Mailbox being migrated
>
> I've tested it, and it works fine if I use the target address of 
> virtual_alias_maps,
> but not if I list the address in the email.  In our case this is to 
> hold/suspend email
> until the mailbox is copied to a second system, where we continue to
> run mail on both mailbox systems.
>
> If I set up entries like:
>
> u...@server1.example.com retry:4.0.0 Mailbox being migrated
>
> That will keep it in the queue all right, but how to release it so it
> will deliver to u...@server2.example.com after mailboxes have
> been moved?  I'd think we'd need a way to hold it prior to getting
> processed by the virtual mapping.
>
>

It is a bit of an ugly kludge, but here is how we are handling it.  There
are a few hundred mailboxes to move to the secondary server - we'll
call the secondary mailbox server server2.example.com here.

On the MX systems, we set up a dummy transport for a server which does
not handle mailboxes.

transport_maps = hash:/etc/postfix/transport, hash:/etc/postfix/migrating

The file 'migrating' contains:

dummy.example.com retry:4.0.0 Mailbox being migrated

The virtual_alias_maps file is set so the migrating users have this
dummy destination.  (We have an automated set of scripts to
manage the mapping and generate postfix conf files.)

u...@example.comu...@dummy.example.com

Now emails for these users are held on the MX systems.

Once the mailboxes have been moved over, we can requeue, using a
temporary transport
redirecting entry for the occassion:

dummy.example.comrelay:[server2.example.com]:25

The virtual mapping conf files are set to the proper target
of @server2.example.com rather than dummy.

Then pass through the messages waiting in the queue.  We have a perl
script which takes
the mailq output and puts each chunk on one line, called oneline.pl.

for qid in `mailq | oneline.pl  | grep '@dummy.example.com' | cut -f1
-d' '`; do postsuper -r $qid; done

Maybe there is a more simple solution, but that's what I've got for now.

Re: Restrictions after postscreen

[Stan Hoeppner]

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,
>>> reject_unknown_reverse_client_hostname,
>>> warn_if_reject reject_unknown_helo_hostname,
>>> check_reverse_client_hostname_access
>> pcre:/etc/postfix/fqrdns.pcre,
>>> check_helo_access hash:/etc/postfix/helo_access,
>>> check_sender_access hash:/etc/postfix/sender_access,
>>> reject_rbl_client zen.spamhaus.org,
>>> reject_rhsbl_client dbl.spamhaus.org,
>>> reject_rhsbl_sender dbl.spamhaus.org,
>>> reject_rhsbl_helo dbl.spamhaus.org,
>>> permit_dnswl_client list.dnswl.org=127.0.[0..255].[1..3],
>>> permit
>>
>> The last two lines are no-op. If you have anything you want to be
>> subjected to the list.dnswl.org whitelist, put it after the
>> permit_dnswl_client. If not, there is no point in querying it.
> 
> 
> Excellent point. If the next step is going to "permit" anyway, then no use
> in the extra query. I've moved the dnswl.org line up so that it's just
> above the three "local" check_* lines.

"permits" always come before "rejects".  Thus whitelist type entries
should always be at the top of the restrictions list.  As you are using
(client|helo|sender|recipient) sections any whitelisting in
smtpd_recipient_restrictions should typically be at the very top.

permit_dnswl_client list.dnswl.org=127.0.[0..255].[1..3]
  ^^   

This shows you are explicitly permitting anything/everything listed in
the dnswl.  Are you sure that is what you want?  I use...

permit_dnswl_client list.dnswl.org=127.0.[2..14].[2..3]

which does not explicitly permit email marketing providers nor any IP
with trustworthiness score of 1.  A score of 1 is equivalent to a
SpamAssassin score of -1, which does not merit a direct shot to the
queue.  That would typically require an SA score of -5.  I want these
clients to go through all of my other restrictions before allowing their
payload into my queue.

Also worth noting, there are currently only 14 categories (3rd octet of
a reply), so specifying 255 is not necessary, and possibly problematic.
 Hypothetically, if dnswl decided one day to create categories 16,
political campaigns, and 17, religious newsletters, you are currently
setup to automatically permit such clients.

Remember, the sole purpose of whitelisting is to bypass all of your
other spam checks and get the mail into your queue unmolested.  IMO, not
every IP listed by dnswl is deserving of this honor, not even close to
all of them.

See section "Return codes" at:  http://www.dnswl.org/tech

-- 
Stan

Re: patch: mitigate CRIME attack

[Scott Kitterman]

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
>there is rising demand for jumping through "stupid hoops" :-).

Discussing that or how to document working around the "issue" would be useful. 
It would be a good topic to discuss on ubuntu-ser...@lists.ubuntu.com.

Scott K