submission port requiring starttls even when set not to
I'm trying to implement a white list with check_sender_access in
smtpd_recipient_restrictions. The problem I'm running into is that the
submission port is requiring TLS even when I have set
smtpd_enforce_tls=no and smtp_enfoce_tls=no in main.cf and specified
them as options for the submission entry master.cf.
The details are, I'm trying to change the transport for white listed
domains so that the spam filters and what not are bypassed. The mail
delivery attempt via the submission port fails every time with Must
issue a STARTTLS command first. I feel confident that I'm overlooking
something obvious but I've given all the various config settings I can
think of an attempt with the same outcome.
This is all dev stuff, none of it is set in stone. If anyone has a
better suggestion on how to bypass the spam filters and what not for
certain domains, I'm ready to listen.
From here on is my postconf -n, white_list file for
check_sender_access, submission entry from master.cf and the relevant
log entries.
postconf -n:
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
content_filter = amavis:[127.0.0.1]:10024
disable_vrfy_command = yes
inet_interfaces = all
mailbox_size_limit = 0
maximal_backoff_time = 300s
message_size_limit = 0
minimal_backoff_time = 120s
mydestination = maildev.judelawfirm.com
myhostname = maildev.judelawfirm.com
mynetworks = 127.0.0.0/8192.168.1.0/24
myorigin = maildev.judelawfirm.com
queue_run_delay = 120s
readme_directory = no
recipient_bcc_maps = pcre:/etc/postfix/recipient_bcc
recipient_delimiter = +
sender_bcc_maps = pcre:/etc/postfix/recipient_bcc
smtp_enforce_tls = no
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name
smtpd_data_restrictions = reject_unauth_pipelining
permit_mynetworks permit_sasl_authenticated
smtpd_enforce_tls = no
smtpd_helo_required = yes
smtpd_helo_restrictions = reject_invalid_hostname
reject_non_fqdn_hostname
smtpd_recipient_restrictions = permit_mynetworks
permit_sasl_authenticated check_sender_access
hash:/etc/postfix/black_listcheck_sender_access
hash:/etc/postfix/white_listreject_unlisted_recipient
reject_non_fqdn_hostnamereject_non_fqdn_sender
reject_non_fqdn_recipient reject_unauth_destination
reject_unauth_pipeliningreject_invalid_hostname
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $myhostname
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
strict_rfc821_envelopes = yes
transport_maps = hash:/etc/postfix/transports
virtual_alias_maps = mysql:/etc/postfix/mysql_virtual_alias_maps.cf
virtual_gid_maps = static:1000
virtual_mailbox_base = /var/vmail
virtual_mailbox_domains = mysql:/etc/postfix/mysql_virtual_domains_maps.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
virtual_minimum_uid = 1000
virtual_transport = dovecot
virtual_uid_maps = static:1000
/etc/postfix/white_list:
gmail.com FILTER smtp:[127.0.0.1]:submission
submission entry from /etc/postfix/master.cf:
submission inet n - - - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_enforce_tls=no
-o smtp_enforce_tls=no
-o mynetworks=127.0.0.0/8
-o
smtpd_client_restrictions=permit_my_networks,permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
-o content_filter=
log entries:
Mar 4 13:48:10 mail1 postfix/smtpd[15692]: connect from
qw-out-2122.google.com[74.125.92.26]
Mar 4 13:48:11 mail1 postfix/smtpd[15692]: NOQUEUE: filter: RCPT from
qw-out-2122.google.com[74.1 25.92.26]: jptroscl...@gmail.com:
Sender address triggers FILTER smtp:[127.0.0.1]:submission; fr
om=jptroscl...@gmail.com to=jptroscl...@itdevel.net proto=ESMTP
helo=qw-out-2122.google.com
Mar 4 13:48:11 mail1 postfix/smtpd[15692]: 35B9C19C717:
client=qw-out-2122.google.com[74.125.92.2 6]
Mar 4 13:48:11 mail1 postfix/cleanup[15697]: 35B9C19C717:
message-id=49aedb33.1020...@gmail.com
Mar 4 13:48:11 mail1 postfix/qmgr[15691]: 35B9C19C717:
from=jptroscl...@gmail.com, size=1989, n rcpt=2 (queue active)
Mar 4 13:48:11 mail1 postfix/smtpd[15699]: connect from
localhost[127.0.0.1]
Mar 4 13:48:11 mail1 postfix/smtp[15698]: 35B9C19C717:
to=jptroscl...@itdevel.net, relay=127.0. 0.1[127.0.0.1]:587,
delay=0.34, delays=0.31/0.01/0.02/0, dsn=5.7.0, status=bounced (host
127.0.0.1 [127.0.0.1] said: 530 5.7.0 Must issue a STARTTLS
command first (in reply to MAIL FROM command))
Mar 4 13:48:11 mail1 postfix/smtp[15698]: 35B9C19C717:
to=jptroscl...@itdevel.net.archive,
Re: submission port requiring starttls even when set not to
J.P. Trosclair wrote: I'm trying to implement a white list with check_sender_access in smtpd_recipient_restrictions. The problem I'm running into is that the submission port is requiring TLS even when I have set smtpd_enforce_tls=no and smtp_enfoce_tls=no in main.cf and specified them as options for the submission entry master.cf. submission entry from /etc/postfix/master.cf: submission inet n - - - - smtpd -o smtpd_tls_security_level=encrypt http://www.postfix.org/postconf.5.html#smtpd_tls_security_level *encrypt* Mandatory TLS encryption: announce STARTTLS support to SMTP clients, and require that clients use TLS encryption. According to RFC 2487 http://tools.ietf.org/html/rfc2487 this MUST NOT be applied in case of a publicly-referenced SMTP server. Instead, this option should be used only on dedicated servers. Brian
Re: submission port requiring starttls even when set not to
On 4-Mar-2009, at 13:08, J.P. Trosclair wrote: submission inet n - - - - smtpd -o smtpd_tls_security_level=encrypt Why? -- If I were you boys, I wouldn't talk or even think about women. T'aint good for your health.
Re: submission port requiring starttls even when set not to (Resolved)
LuKreme wrote: On 4-Mar-2009, at 13:08, J.P. Trosclair wrote: submission inet n - - - - smtpd -o smtpd_tls_security_level=encrypt Why? I didn't explicitly add it. It was a left over from the default master.cf for the postfix package on debian 5.0. It's gone and everything is good, for now.
Re: submission port requiring starttls even when set not to (Resolved)
J.P. Trosclair wrote, at 03/04/2009 04:05 PM: LuKreme wrote: On 4-Mar-2009, at 13:08, J.P. Trosclair wrote: submission inet n - - - - smtpd -o smtpd_tls_security_level=encrypt Why? I didn't explicitly add it. It was a left over from the default master.cf for the postfix package on debian 5.0. It's gone and everything is good, for now. Put it back. smtpd_enforce_tls is deprecated since Postfix 2.3 and smtpd_tls_security_level should be used instead. Furthermore, you should leave it set to encrypt. Part of the value of running a submission service on port 587 is that it allows you to severely restrict connections in a way that is acceptable to ISPs, who are blocking outgoing connections to SMTP port 25. If admins begin relaxing the restrictions on port 587 without understanding the ramifications, ISPs might start blocking it, too, which is bad for residential and roaming users who need it in order to relay mail through the desired server. An important part of this is encrypting all connections to port 587. It's easy enough to set up another (local) port in master.cf that will serve your purpose (or someone might even be able to suggest an alternative approach).
Re: submission port requiring starttls even when set not to (Resolved)
Jorey Bump wrote: Put it back. smtpd_enforce_tls is deprecated since Postfix 2.3 and smtpd_tls_security_level should be used instead. I'll research the smtpd_tls_security_level option further. It didn't present a problem until I started working on this specific feature with the white lists. I have created another smtpd instance to forward white listed domains to rather than trying to utilize the submission port. I felt like I was over-complicating (because of archiving with *_bcc_maps and duplicate mails) the functionality of the submission service and thus headed down a bumpy road, maybe I'm wrong about this though. At the same time the submission service seems like the ideal place to hand this mail over to for final delivery since it's intended (for us) to allow trusted clients to bypass filtering and spam checks.
Re: submission port requiring starttls even when set not to (Resolved)
On 4-Mar-2009, at 14:33, Jorey Bump wrote: smtpd_tls_security_level should be used instead. Not if you don't want to force TLS on the submission port it shouldn't. On 4-Mar-2009, at 13:21, Brian Evans - Postfix List wrote: *encrypt* Mandatory TLS encryption: announce STARTTLS support to SMTP clients, and require that clients use TLS encryption. According to RFC 2487 http://tools.ietf.org/html/rfc2487 this MUST NOT be applied in case of a publicly-referenced SMTP server. Instead, this option should be used only on dedicated servers. This is wrong too (not he quote, but Brian's missaplication of it). From RFC287 A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally. So far so good, but keep reading: This rule prevents the STARTTLS extension from damaging the interoperability of the Internet's SMTP infrastructure. ***A publicly-referenced SMTP server is an SMTP server which runs on port 25 of an Internet host listed in the MX record (or A record if an MX record is not present) for the domain name on the right hand side of an Internet mail address***. So that has nothing to do with the submission port. -- When the routine bites hard / and ambitions are low And the resentment rides high / but emotions won't grow And we're changing our ways, / taking different roads Then love, love will tear us apart again
Re: submission port requiring starttls even when set not to (Resolved)
LuKreme wrote, at 03/04/2009 05:24 PM: On 4-Mar-2009, at 14:33, Jorey Bump wrote: smtpd_tls_security_level should be used instead. Not if you don't want to force TLS on the submission port it shouldn't. The context is irrelevant. smtpd_tls_security_level is the new parameter that replaces smtpd_enforce_tls, which is still available for backwards compatibility. postconf(5) has this to say about smtpd_enforce_tls: This feature is available in Postfix 2.2 and later. With Postfix 2.3 and later use smtpd_tls_security_level instead.
Re: submission port requiring starttls even when set not to (Resolved)
On 4-Mar-2009, at 19:12, Jorey Bump wrote: LuKreme wrote, at 03/04/2009 05:24 PM: On 4-Mar-2009, at 14:33, Jorey Bump wrote: smtpd_tls_security_level should be used instead. Not if you don't want to force TLS on the submission port it shouldn't. The context is irrelevant. Of course the context is relevant since the original poster did not want TLS *AT ALL* on the submission port. Which syntax is right for enabling a feature he DOESN'T WANT is silliness. -- In my world there are people in chains and you can ride them like ponies
Re: submission port requiring starttls even when set not to (Resolved)
J.P. Trosclair wrote, at 03/04/2009 05:01 PM: I'll research the smtpd_tls_security_level option further. It didn't present a problem until I started working on this specific feature with the white lists. I have created another smtpd instance to forward white listed domains to rather than trying to utilize the submission port. I felt like I was over-complicating (because of archiving with *_bcc_maps and duplicate mails) the functionality of the submission service and thus headed down a bumpy road, maybe I'm wrong about this though. At the same time the submission service seems like the ideal place to hand this mail over to for final delivery since it's intended (for us) to allow trusted clients to bypass filtering and spam checks. Yes, it can be. For example, it's perfectly reasonable to include mynetworks in the submission port's smtpd_client_restrictions, then add whitelisted hosts to mynetworks. But this is really true only for hosts under your control, and not recommended for whitelisting whole external domains. For obvious reasons, it would be insane to add gmail.com to mynetworks. Unfortunately, your originally proposed solution weakens security for all clients using the submission port, including authenticating clients. A workaround is possible with these settings: -o smtpd_tls_security_level=may -o smtpd_tls_auth_only=yes But I would discourage this approach on the public submission port, as it's best to provide maximum security by encrypting all connections. When you must relax this restriction, add another port to master.cf that you can fine-tune for the intended purpose. This also allows you to apply firewall rules that would be inappropriate for a public submission service on port 587, enabling you to lock it down tightly.
Re: submission port requiring starttls even when set not to (Resolved)
LuKreme wrote, at 03/04/2009 09:25 PM: On 4-Mar-2009, at 19:12, Jorey Bump wrote: LuKreme wrote, at 03/04/2009 05:24 PM: On 4-Mar-2009, at 14:33, Jorey Bump wrote: smtpd_tls_security_level should be used instead. Not if you don't want to force TLS on the submission port it shouldn't. The context is irrelevant. Of course the context is relevant since the original poster did not want TLS *AT ALL* on the submission port. Which syntax is right for enabling a feature he DOESN'T WANT is silliness. Please read postconf(5). The recommended syntax for disabling TLS is: smtpd_tls_security_level=none The deprecated syntax is: smtpd_enforce_tls=no The OP was using both parameters with conflicting values: -o smtpd_tls_security_level=encrypt -o smtpd_enforce_tls=no He solved his original problem by removing the recommended parameter and leaving the deprecated one. In this case, he should have removed smtpd_enforce_tls and set smtpd_tls_security_level appropriately. It is not silliness to advise him to use the recommended syntax. Nor is it inappropriate to point out the pitfalls of the proposed setting, especially when he asked for suggestions.
