New default settings for "submission" service?

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

New default settings for "submission" service?

Patrick Ben Koetter
Wietse et al.

With the arrival of postscreen, but also before I find myself repeatedly
changing the defaults for the 'submission' service in master.cf. I believe the
changes I apply are not rooted in my local mail policies, but of general
nature.

Now that submission has become more popular I'd like to discuss if the current
settings should be modified to work better with an MTA that runs different
policies for port 25 and 587, which I believe has become the standard use case
for 'a mailserver'.

In RFC 5598 "Internet Mail Architecture" Dave Crocker writes about the
submission service:

4.3.1.  Mail Submission Agent (MSA)

   A Mail Submission Agent (MSA) accepts the message submitted by the
   aMUA and enforces the policies of the hosting ADMD and the
   requirements of Internet standards.  An MSA represents an unusual
   functional dichotomy.  It represents the interests of the Author
   (aMUA) during message posting, to facilitate posting success; it also
   represents the interests of the MHS.
   
   ...

   The hMSA takes transit responsibility for a message that conforms to
   the relevant Internet standards and to local site policies.  It
   rejects messages that are not in conformance.  The MSA performs final
   message preparation for submission and effects the transfer of
   responsibility to the MHS, via the hMSA.  The amount of preparation
   depends upon the local implementations.  Examples of aMSA tasks
   include adding header fields, such as Date: and Message-ID:, and
   modifying portions of the message from local notations to Internet
   standards, such as expanding an address to its formal IMF
   representation.
   -- http://tools.ietf.org/rfc/rfc5598.txt

This said, I think the submission service should be expanded and modified.

I would add the following filters to reject "messages that are not in
conformance" in order to gain basic transportability and better deliverabilty:

reject_non_fqdn_sender
reject_non_fqdn_recipient
reject_unknown_sender_domain
reject_unkown_recipient_domain

I'd also add header fields if the authenticated client failed to:

always_add_missing_headers=yes

And finally I'd change the current settings for smtpd_tls_security_level and
smtpd_delay_reject regarding the submission service:

smtpd_tls_security_level
I would not enforce TLS as the submission RFC only says "SHOULD" on TLS and
therefore would only set 'may' as preconfigured setting. I'd leave it to the
postmaster to set a stricter policy. I personally keep changing this all the
time since I configure and test SASL first and once that works as expected
turn to TLS. Opportunistic TLS as default would make this easier without
breaking RFCs.

smtpd_delay_reject
For convenience reasons I'd add this setting and set it to 'yes'. Eversince
postscreen has been around I've been switching to smtpd_delay_reject=no and
more aggressive filtering on port 25. I believe many have done so.
Unfortunately setting it to 'no' breaks the assigned smtpd_client_restrictions
for the submission service - the client will be rejected before it was able to
authenticate.


All in all I think these changes would make a submission service more useful
out of the box.

What do you think?

p@rick

--
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):
<http://postfix.state-of-mind.de/patrick.koetter/saslfinger/>
Reply | Threaded
Open this post in threaded view
|

Re: New default settings for "submission" service?

Wietse Venema
Patrick Ben Koetter:

> Wietse et al.
>
> With the arrival of postscreen, but also before I find myself repeatedly
> changing the defaults for the 'submission' service in master.cf. I believe the
> changes I apply are not rooted in my local mail policies, but of general
> nature.
>
> Now that submission has become more popular I'd like to discuss if the current
> settings should be modified to work better with an MTA that runs different
> policies for port 25 and 587, which I believe has become the standard use case
> for 'a mailserver'.

Indeed. Of course, not every MTA needs to provide "port 587"
submission service. Enabling an unused service by default would be
undesirable as it may produce unexpected results.

Different sites have different needs, and perhaps it is an idea to
provide *multiple* submission service examples in master.cf, all
commented out of course. The first could be the recommended one:
not allowing plaintext sessions is good as a general rule. The
second example could allow plaintext sessions (level = may) but
allow plaintext passwords only over encrypted sessions.

I would not recommend smtpd_delay_reject=no.  With that, the sysadmin
has no clue about what mail is blocked.  Even postscreen tries to
capture sender and recipient information.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: New default settings for "submission" service?

Patrick Ben Koetter
* Wietse Venema <[hidden email]>:

> Patrick Ben Koetter:
> > Wietse et al.
> >
> > With the arrival of postscreen, but also before I find myself repeatedly
> > changing the defaults for the 'submission' service in master.cf. I believe the
> > changes I apply are not rooted in my local mail policies, but of general
> > nature.
> >
> > Now that submission has become more popular I'd like to discuss if the current
> > settings should be modified to work better with an MTA that runs different
> > policies for port 25 and 587, which I believe has become the standard use case
> > for 'a mailserver'.
>
> Indeed. Of course, not every MTA needs to provide "port 587"
> submission service. Enabling an unused service by default would be
> undesirable as it may produce unexpected results.

Agreed.


> Different sites have different needs, and perhaps it is an idea to
> provide *multiple* submission service examples in master.cf, all
> commented out of course. The first could be the recommended one:
> not allowing plaintext sessions is good as a general rule. The
> second example could allow plaintext sessions (level = may) but
> allow plaintext passwords only over encrypted sessions.

I'll be on a train for quite some time today. That will give me time to work
out some examples.


> I would not recommend smtpd_delay_reject=no.  With that, the sysadmin
> has no clue about what mail is blocked.  Even postscreen tries to
> capture sender and recipient information.

You would not recommend it in general or not on 587? The latter would be my
recommendation:

- Do not delay on port 25 for MTA to MTA communication
- Delay on port 587 for MUA to MTA communication

p@rick

--
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):
<http://postfix.state-of-mind.de/patrick.koetter/saslfinger/>
Reply | Threaded
Open this post in threaded view
|

Re: New default settings for "submission" service?

Ralf Hildebrandt
* Patrick Ben Koetter <[hidden email]>:

> You would not recommend it in general or not on 587? The latter would be my
> recommendation:
>
> - Do not delay on port 25 for MTA to MTA communication
> - Delay on port 587 for MUA to MTA communication

I'd keep smtpd_delay_reject at its default for both 25 & 587

--
Ralf Hildebrandt
  Geschäftsbereich IT | Abteilung Netzwerk
  Charité - Universitätsmedizin Berlin
  Campus Benjamin Franklin
  Hindenburgdamm 30 | D-12203 Berlin
  Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962
  [hidden email] | http://www.charite.de
           
Reply | Threaded
Open this post in threaded view
|

Re: New default settings for "submission" service?

Wietse Venema
In reply to this post by Patrick Ben Koetter
Patrick Ben Koetter:
> - Do not delay on port 25 for MTA to MTA communication

With this. the sysadmin has no clue about what mail is blocked.
Even postscreen goes through great efforts to report the
sender and recipient of blocked mail.

Recommending this change would be a major mistake.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: New default settings for "submission" service?

Nerijus Kislauskas
In reply to this post by Wietse Venema
On 03/13/2012 01:51 AM, Wietse Venema wrote:
> The first could be the recommended one:
> not allowing plaintext sessions is good as a general rule. The
> second example could allow plaintext sessions (level = may) but
> allow plaintext passwords only over encrypted sessions.

While ninjas are being busy with lives, our submission configuration is
as follows:

smtpd_sasl_auth_enable=yes
smtpd_tls_security_level=may
smtpd_tls_auth_only=yes

and mynetworks is of course my client networks. Works good so far (about
a month).
--
Sincerely,
Nerijus Kislauskas
Reply | Threaded
Open this post in threaded view
|

Re: New default settings for "submission" service?

Patrick Domack
In reply to this post by Wietse Venema
Quoting Wietse Venema <[hidden email]>:

> Patrick Ben Koetter:
>> - Do not delay on port 25 for MTA to MTA communication
>
> With this. the sysadmin has no clue about what mail is blocked.
> Even postscreen goes through great efforts to report the
> sender and recipient of blocked mail.

Along these lines, would patching the enforce blacklist, so that it  
logs the from/to without doing dnsbl's be useful? I can't think of a  
purpose why, if you have them in the blacklist, you would also want to  
do all those dns rbl lookups also, but I do want to get the from/to so  
I can locate something if a user requests it.

This patch causes postscreen_blacklist_action = enforce to not  
generate dnsbl lookups.

--- src/postscreen/postscreen_dnsbl.c 2012-01-09 19:31:52.000000000 -0500
+++ src/postscreen/postscreen_dnsbl.c 2012-03-10 08:10:46.261969063 -0500
@@ -491,6 +491,7 @@
       * We therefore do not optimize the maximum out of this temporary
       * implementation.
       */
+    if ( (((PSC_STATE *)context)->flags & PSC_STATE_FLAG_BLIST_FAIL) == 0) {
      for (ht = dnsbl_site_list; *ht; ht++) {
  if ((fd = LOCAL_CONNECT(psc_dnsbl_service, NON_BLOCKING, 1)) < 0) {
     msg_warn("%s: connect to %s service: %m",
@@ -513,6 +514,7 @@
        (char *) stream, DNSBLOG_TIMEOUT);
  score->pending_lookups += 1;
      }
+    }
      return (PSC_CALL_BACK_INDEX_OF_LAST(score));
  }



Reply | Threaded
Open this post in threaded view
|

Re: New default settings for "submission" service?

Wietse Venema
Patrick Domack:

> Quoting Wietse Venema <[hidden email]>:
>
> > Patrick Ben Koetter:
> >> - Do not delay on port 25 for MTA to MTA communication
> >
> > With this. the sysadmin has no clue about what mail is blocked.
> > Even postscreen goes through great efforts to report the
> > sender and recipient of blocked mail.
>
> Along these lines, would patching the enforce blacklist, so that it  
> logs the from/to without doing dnsbl's be useful? I can't think of a  

This replaces one hard-coded behavior (apply all configured tests)
with different hard-coded behavior (skip some arbitrary subset of
configured tests), making postfix more difficult to understand, in
the hope of achieving a minor performance optimization.

The reason to apply all configured tests is to find out how effective
all tests are, even if a bot is blocked by the first one.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: New default settings for "submission" service?

Patrick Ben Koetter
In reply to this post by Patrick Ben Koetter
* Patrick Ben Koetter <[hidden email]>:
> * Wietse Venema <[hidden email]>:
> > Different sites have different needs, and perhaps it is an idea to
> > provide *multiple* submission service examples in master.cf, all
> > commented out of course. The first could be the recommended one:
> > not allowing plaintext sessions is good as a general rule. The
> > second example could allow plaintext sessions (level = may) but
> > allow plaintext passwords only over encrypted sessions.

Here are two examples we all seem to agree on. They differ in TLS
(optional/mandatory) and the SASL mechanisms they allow depending on the TLS
context.

Additionally, both examples have SMTP session filters that check for syntactic
deliverability (MSA job) and add required headers if they are missing.

Filters and fixing headers is a change I'd propose, but nobody seems to have
commented on yet. Agreed by everyone?

As a safety net I would change smtpd_client_restrictions into
smtpd_recipient_restrictions. This will give a client sufficient time to
authenticate and permit_sasl_authenticated will work even if an admin changed
the defaults for smtpd_delay_reject. It also makes it possible to filter for
reject_non_fqdn_recipient, which the RFC I quoted says to be a MSA job.


# submission example 1: Optional TLS with SASL methods safe to use over an
# unencrypted network
#submission inet n       -       -       -       -       smtpd
#  -o smtpd_tls_security_level=may
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_sasl_security_options=noplaintext,noanonymous
#  -o smtpd_tls_sasl_security_options=noanonymous
#  -o always_add_missing_headers=yes
#  -o smtpd_recipient_restrictions=reject_non_fqdn_sender,reject_non_fqdn_recipient,permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING


# submission example 2: Mandatory TLS and SASL only over an encrypted network
#submission inet n       -       -       -       -       smtpd
#  -o smtpd_tls_security_level=enforce
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_tls_auth_only=yes
#  -o always_add_missing_headers=yes
#  -o smtpd_recipient_restrictions=reject_non_fqdn_sender,reject_non_fqdn_recipient,permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING

--
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):
<http://postfix.state-of-mind.de/patrick.koetter/saslfinger/>
Reply | Threaded
Open this post in threaded view
|

Re: New default settings for "submission" service?

Robert Schetterer
Am 13.03.2012 17:37, schrieb Patrick Ben Koetter:

> * Patrick Ben Koetter <[hidden email]>:
>> * Wietse Venema <[hidden email]>:
>>> Different sites have different needs, and perhaps it is an idea to
>>> provide *multiple* submission service examples in master.cf, all
>>> commented out of course. The first could be the recommended one:
>>> not allowing plaintext sessions is good as a general rule. The
>>> second example could allow plaintext sessions (level = may) but
>>> allow plaintext passwords only over encrypted sessions.
>
> Here are two examples we all seem to agree on. They differ in TLS
> (optional/mandatory) and the SASL mechanisms they allow depending on the TLS
> context.
>
> Additionally, both examples have SMTP session filters that check for syntactic
> deliverability (MSA job) and add required headers if they are missing.
>
> Filters and fixing headers is a change I'd propose, but nobody seems to have
> commented on yet. Agreed by everyone?
>
> As a safety net I would change smtpd_client_restrictions into
> smtpd_recipient_restrictions. This will give a client sufficient time to
> authenticate and permit_sasl_authenticated will work even if an admin changed
> the defaults for smtpd_delay_reject. It also makes it possible to filter for
> reject_non_fqdn_recipient, which the RFC I quoted says to be a MSA job.
>
>
> # submission example 1: Optional TLS with SASL methods safe to use over an
> # unencrypted network
> #submission inet n       -       -       -       -       smtpd
> #  -o smtpd_tls_security_level=may
> #  -o smtpd_sasl_auth_enable=yes
> #  -o smtpd_sasl_security_options=noplaintext,noanonymous
> #  -o smtpd_tls_sasl_security_options=noanonymous
> #  -o always_add_missing_headers=yes
> #  -o smtpd_recipient_restrictions=reject_non_fqdn_sender,reject_non_fqdn_recipient,permit_sasl_authenticated,reject
> #  -o milter_macro_daemon_name=ORIGINATING
>
>
> # submission example 2: Mandatory TLS and SASL only over an encrypted network
> #submission inet n       -       -       -       -       smtpd
> #  -o smtpd_tls_security_level=enforce
> #  -o smtpd_sasl_auth_enable=yes
> #  -o smtpd_tls_auth_only=yes
> #  -o always_add_missing_headers=yes
> #  -o smtpd_recipient_restrictions=reject_non_fqdn_sender,reject_non_fqdn_recipient,permit_sasl_authenticated,reject
> #  -o milter_macro_daemon_name=ORIGINATING
>

Hi Patrick,

always_add_missing_headers (default: no)

    Always add (Resent-) From:, To:, Date: or Message-ID: headers when
not present. Postfix 2.6 and later add these headers only when clients
match the local_header_rewrite_clients parameter setting. Earlier
Postfix versions always add these headers; this may break DKIM
signatures that cover non-existent headers.

are you sure that your example is safe with i.e dkim ?

--
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria
Reply | Threaded
Open this post in threaded view
|

Re: New default settings for "submission" service?

Scott Kitterman-4
On Tuesday, March 13, 2012 07:46:09 PM Robert Schetterer wrote:

> Am 13.03.2012 17:37, schrieb Patrick Ben Koetter:
> > * Patrick Ben Koetter <[hidden email]>:
> >> * Wietse Venema <[hidden email]>:
> >>> Different sites have different needs, and perhaps it is an idea to
> >>> provide *multiple* submission service examples in master.cf, all
> >>> commented out of course. The first could be the recommended one:
> >>> not allowing plaintext sessions is good as a general rule. The
> >>> second example could allow plaintext sessions (level = may) but
> >>> allow plaintext passwords only over encrypted sessions.
> >
> > Here are two examples we all seem to agree on. They differ in TLS
> > (optional/mandatory) and the SASL mechanisms they allow depending on the
> > TLS context.
> >
> > Additionally, both examples have SMTP session filters that check for
> > syntactic deliverability (MSA job) and add required headers if they are
> > missing.
> >
> > Filters and fixing headers is a change I'd propose, but nobody seems to
> > have commented on yet. Agreed by everyone?
> >
> > As a safety net I would change smtpd_client_restrictions into
> > smtpd_recipient_restrictions. This will give a client sufficient time to
> > authenticate and permit_sasl_authenticated will work even if an admin
> > changed the defaults for smtpd_delay_reject. It also makes it possible
> > to filter for reject_non_fqdn_recipient, which the RFC I quoted says to
> > be a MSA job.
> >
> >
> > # submission example 1: Optional TLS with SASL methods safe to use over
> > an # unencrypted network
> > #submission inet n       -       -       -       -       smtpd
> > #  -o smtpd_tls_security_level=may
> > #  -o smtpd_sasl_auth_enable=yes
> > #  -o smtpd_sasl_security_options=noplaintext,noanonymous
> > #  -o smtpd_tls_sasl_security_options=noanonymous
> > #  -o always_add_missing_headers=yes
> > #  -o
> > smtpd_recipient_restrictions=reject_non_fqdn_sender,reject_non_fqdn_rec
> > ipient,permit_sasl_authenticated,reject #  -o
> > milter_macro_daemon_name=ORIGINATING
> >
> >
> > # submission example 2: Mandatory TLS and SASL only over an encrypted
> > network #submission inet n       -       -       -       -       smtpd
> > #  -o smtpd_tls_security_level=enforce
> > #  -o smtpd_sasl_auth_enable=yes
> > #  -o smtpd_tls_auth_only=yes
> > #  -o always_add_missing_headers=yes
> > #  -o
> > smtpd_recipient_restrictions=reject_non_fqdn_sender,reject_non_fqdn_rec
> > ipient,permit_sasl_authenticated,reject #  -o
> > milter_macro_daemon_name=ORIGINATING
>
> Hi Patrick,
>
> always_add_missing_headers (default: no)
>
>     Always add (Resent-) From:, To:, Date: or Message-ID: headers when
> not present. Postfix 2.6 and later add these headers only when clients
> match the local_header_rewrite_clients parameter setting. Earlier
> Postfix versions always add these headers; this may break DKIM
> signatures that cover non-existent headers.
>
> are you sure that your example is safe with i.e dkim ?

The MSA should be doing the signing, not the MUA, so it should be.

Scott K
Reply | Threaded
Open this post in threaded view
|

Re: New default settings for "submission" service?

mouss-4
In reply to this post by Patrick Ben Koetter
Le 13/03/2012 00:25, Patrick Ben Koetter a écrit :

> Wietse et al.
>
> With the arrival of postscreen, but also before I find myself repeatedly
> changing the defaults for the 'submission' service in master.cf. I believe the
> changes I apply are not rooted in my local mail policies, but of general
> nature.
>
> Now that submission has become more popular I'd like to discuss if the current
> settings should be modified to work better with an MTA that runs different
> policies for port 25 and 587, which I believe has become the standard use case
> for 'a mailserver'.
>
>[sip]
>
> I would add the following filters to reject "messages that are not in
> conformance" in order to gain basic transportability and better deliverabilty:
>
> reject_non_fqdn_sender
> reject_non_fqdn_recipient
> reject_unknown_sender_domain
> reject_unkown_recipient_domain
>

while I like such checks in order to detect virus/trojan attacks, we're
not there yet. more efforts are needed to educate hosters as well as
application developers



> I'd also add header fields if the authenticated client failed to:
>
> always_add_missing_headers=yes
>
> And finally I'd change the current settings for smtpd_tls_security_level and
> smtpd_delay_reject regarding the submission service:
>
> smtpd_tls_security_level
> I would not enforce TLS as the submission RFC only says "SHOULD" on TLS and
> therefore would only set 'may' as preconfigured setting. I'd leave it to the
> postmaster to set a stricter policy. I personally keep changing this all the
> time since I configure and test SASL first and once that works as expected
> turn to TLS. Opportunistic TLS as default would make this easier without
> breaking RFCs.
>
> smtpd_delay_reject
> For convenience reasons I'd add this setting and set it to 'yes'. Eversince
> postscreen has been around I've been switching to smtpd_delay_reject=no and
> more aggressive filtering on port 25. I believe many have done so.
> Unfortunately setting it to 'no' breaks the assigned smtpd_client_restrictions
> for the submission service - the client will be rejected before it was able to
> authenticate.
>
>
> All in all I think these changes would make a submission service more useful
> out of the box.
>
> What do you think?
>
> p@rick
>

Reply | Threaded
Open this post in threaded view
|

Re: New default settings for "submission" service?

Patrick Ben Koetter
Hey mouss,

* mouss <[hidden email]>:

> Le 13/03/2012 00:25, Patrick Ben Koetter a écrit :
> > Wietse et al.
> >
> > With the arrival of postscreen, but also before I find myself repeatedly
> > changing the defaults for the 'submission' service in master.cf. I believe the
> > changes I apply are not rooted in my local mail policies, but of general
> > nature.
> >
> > Now that submission has become more popular I'd like to discuss if the current
> > settings should be modified to work better with an MTA that runs different
> > policies for port 25 and 587, which I believe has become the standard use case
> > for 'a mailserver'.
> >
> >[sip]
> >
> > I would add the following filters to reject "messages that are not in
> > conformance" in order to gain basic transportability and better deliverabilty:
> >
> > reject_non_fqdn_sender
> > reject_non_fqdn_recipient
> > reject_unknown_sender_domain
> > reject_unkown_recipient_domain
> >
>
> while I like such checks in order to detect virus/trojan attacks, we're
> not there yet. more efforts are needed to educate hosters as well as
> application developers

my intentions in this effort are not to educate anyone. That's out of my
control. I want to do what I can control and prepare submitted messages for a
safe journey i.e. make sure they meet the technical standards for best
deliverability.

Of course, I'd require application developers to write software that meets the
standard requirements, but that's a different story to me.

p@rick

--
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):
<http://postfix.state-of-mind.de/patrick.koetter/saslfinger/>
Reply | Threaded
Open this post in threaded view
|

Re: New default settings for "submission" service?

Wietse Venema
I'm going to keep it simple: one template for the submission (port 587)
service, and one for smtps (which still seems to be needed in some
places). Three mail submission-like templates becomes unwieldy.

- Both templates override the main.cf settings for smtpd_*_restrictions
to avoid surprises when changes are made to the "port 25" configuration.

- There are no extra syntax or domain existence checks. On the
contrary, I would suggest "-o smtpd_reject_unlisted_recipient=no"
because MUAs do not handle "user unknown" reject messages well. It
may be better to drop such notifications into the user's mailbox.

- These overrides are parametrized to encourage setting them in
main.cf instead of master.cf. Managing such parameters in main.cf
is a realistic possibility now that postconf actually has a clue
about master.cf settings.

#submission inet n       -       n       -       -       smtpd
#  -o syslog_name=postfix/submission
#  -o smtpd_tls_security_level=encrypt
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_reject_unlisted_recipient=no
#  -o smtpd_client_restrictions=$mua_client_restrictions
#  -o smtpd_helo_restrictions=$mua_helo_restrictions
#  -o smtpd_sender_restrictions=$mua_sender_restrictions
#  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING

#smtps     inet  n       -       n       -       -       smtpd
#  -o syslog_name=postfix/smtps
#  -o smtpd_tls_wrappermode=yes
#  -o smtpd_sasl_auth_enable=yes
#  -o smtpd_reject_unlisted_recipient=no
#  -o smtpd_client_restrictions=$mua_client_restrictions
#  -o smtpd_helo_restrictions=$mua_helo_restrictions
#  -o smtpd_sender_restrictions=$mua_sender_restrictions
#  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING

The mua_*_restrictions pseudo-parameters may be set in main.cf.
If, for example, mua_client_restrictions were to be set in main.cf,
then it would control both mail submission services. Otherwise,
the mua_*_restrictions pseudo-parameters all have empty values.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: New default settings for "submission" service?

Ed Wildgoose-2
On 13/03/2012 23:50, Wietse Venema wrote:
> #submission inet n       -       n       -       -       smtpd
> #  -o syslog_name=postfix/submission
> #  -o smtpd_tls_security_level=encrypt

I forget the exact details now, but one mail client, I think it might be
an Android or iPhone mail client(?) defaults to using the submission
service but without encryption.  The error messages were confusing and
unhelpful to the customer and I just recall it took some time to realise
that it was the enforced tls requirement that was the problem

I see no reason to *require* encryption on the submission port (RFC
aside).  I think "may" is a more appropriate default?

Ed W
Reply | Threaded
Open this post in threaded view
|

Re: New default settings for "submission" service?

Charles Marcus
On 2012-03-14 2:39 PM, Ed W <[hidden email]> wrote:
> I see no reason to *require* encryption on the submission port (RFC
> aside).

Unless you prefer that sniffers not be able to see your passwords
crossing the wire in plaintext?

> I think "may" is a more appropriate default?

Disagree vehemently.

--

Best regards,

Charles
Reply | Threaded
Open this post in threaded view
|

Re: New default settings for "submission" service?

Wietse Venema
In reply to this post by Ed Wildgoose-2
Ed W:

> On 13/03/2012 23:50, Wietse Venema wrote:
> > #submission inet n       -       n       -       -       smtpd
> > #  -o syslog_name=postfix/submission
> > #  -o smtpd_tls_security_level=encrypt
>
> I forget the exact details now, but one mail client, I think it might be
> an Android or iPhone mail client(?) defaults to using the submission
> service but without encryption.  The error messages were confusing and
> unhelpful to the customer and I just recall it took some time to realise
> that it was the enforced tls requirement that was the problem
>
> I see no reason to *require* encryption on the submission port (RFC
> aside).  I think "may" is a more appropriate default?

That's not a problem for me. I don't use the submission service
and rely on input from the real world for this.

        Wietse

Reply | Threaded
Open this post in threaded view
|

Re: New default settings for "submission" service?

Wietse Venema
Wietse Venema:

> Ed W:
> > On 13/03/2012 23:50, Wietse Venema wrote:
> > > #submission inet n       -       n       -       -       smtpd
> > > #  -o syslog_name=postfix/submission
> > > #  -o smtpd_tls_security_level=encrypt
> >
> > I forget the exact details now, but one mail client, I think it might be
> > an Android or iPhone mail client(?) defaults to using the submission
> > service but without encryption.  The error messages were confusing and
> > unhelpful to the customer and I just recall it took some time to realise
> > that it was the enforced tls requirement that was the problem
> >
> > I see no reason to *require* encryption on the submission port (RFC
> > aside).  I think "may" is a more appropriate default?
>
> That's not a problem for me. I don't use the submission service
> and rely on input from the real world for this.

Meaning, "may", combined with a setting that allows plaintext
passwords only over encrypted connections.  Not sure if that makes
trouble shooting easier than when TLS is always required, though.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: New default settings for "submission" service?

Patrick Ben Koetter
In reply to this post by Charles Marcus
* Charles Marcus <[hidden email]>:

> On 2012-03-14 2:39 PM, Ed W <[hidden email]> wrote:
> >I see no reason to *require* encryption on the submission port (RFC
> >aside).
>
> Unless you prefer that sniffers not be able to see your passwords
> crossing the wire in plaintext?
>
> >I think "may" is a more appropriate default?
>
> Disagree vehemently.

The RFC on submission is clear about that. It says SHOULD and not MUST. It is
safe to AUTH if you use cram-md5, digest-md5, ntlm or any other non-plaintext
mechanism. Forcing TLS by default is safer, but it pushes a policy on people
the SHOULD decide themselves, I think.

p@rick

--
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):
<http://postfix.state-of-mind.de/patrick.koetter/saslfinger/>
Reply | Threaded
Open this post in threaded view
|

Re: New default settings for "submission" service?

Patrick Ben Koetter
In reply to this post by Wietse Venema
* Wietse Venema <[hidden email]>:

> Wietse Venema:
> > Ed W:
> > > On 13/03/2012 23:50, Wietse Venema wrote:
> > > > #submission inet n       -       n       -       -       smtpd
> > > > #  -o syslog_name=postfix/submission
> > > > #  -o smtpd_tls_security_level=encrypt
> > >
> > > I forget the exact details now, but one mail client, I think it might be
> > > an Android or iPhone mail client(?) defaults to using the submission
> > > service but without encryption.  The error messages were confusing and
> > > unhelpful to the customer and I just recall it took some time to realise
> > > that it was the enforced tls requirement that was the problem
> > >
> > > I see no reason to *require* encryption on the submission port (RFC
> > > aside).  I think "may" is a more appropriate default?
> >
> > That's not a problem for me. I don't use the submission service
> > and rely on input from the real world for this.
>
> Meaning, "may", combined with a setting that allows plaintext
> passwords only over encrypted connections.  Not sure if that makes
> trouble shooting easier than when TLS is always required, though.

It does. One can test CRAM-MD5 also in a telnet session. The SASL_README
refers to a script, gen-auth, that assists creating the necessary response.

p@rick


--
All technical questions asked privately will be automatically answered on the
list and archived for public access unless privacy is explicitely required and
justified.

saslfinger (debugging SMTP AUTH):
<http://postfix.state-of-mind.de/patrick.koetter/saslfinger/>
123