RE: postfix 2.6.6 / always_add_missing_headers behavior question
-Original Message- >2.6.6, though many years past EOL, is indeed later than 2.6, so WHEN [the >listed headers are] NOT >PRESENT they are added ONLY WHEN CLIENTS MATCH THE >local_header_rewrite_clients >PARAMETER SETTING. That's the default setting >of "no" for always_add_missing_headers. > >The Postfix 2.5 and prior behavior was to ALWAYS add these headers if missing, >regardless of the >client address. Thank you.
Re: SMTP session caching
Viktor Dukhovni: > > > > On Mar 21, 2018, at 9:46 PM, Wietse Venema wrote: > > > > Just like the SMTP conection cache service, the tlsproxy service > > must not try to do clever things. It receives TLS requirements, > > does a TLS handshake, and returns TLS session properties that can > > later be used to create a connection cache index. If it needs to > > impersonate a delivery agent, then it gets that nanme from the > > Postfix SMTP client. > > I'd like to avoid having to fully instantiate the SSL_CTX for each > and every connection, SSL_CTX initialization can be expensive. > Thus, the agent name requirement, and re-use of SSL_CTX built for > previous clients with the same name. Currently, the Postfix SMTP client does a bunch of TLS initialization, once per TLS session. The tlsproxy service will do exactly the same TLS initialization once per TLS session. In addition we shuttle some serialized SMTP client state between SMTP client, tlsproxy process, and scache daemon. Conceptualy, that serialized state is just another RPC message. Cached TLS session: scache daemon -> tlsproxy -> remote SMTP server Reused TLS session, or new TLS session: smtp client -> tlsproxy -> remote SMTP server Initial SMTP handshake: smtp client -> remote SMTP server > All in all this is a non-trivial bit of work... Meh. Where I work now, we solve harder problems. Wietse
Re: SMTP session caching
> On Mar 22, 2018, at 10:54 AM, Wietse Venema wrote: > > Currently, the Postfix SMTP client does a bunch of TLS initialization, > once per TLS session. The expensive stuff for SSL_CTX happens only once in tls_client_init(). You're only looking at tls_client_start(), which uses a previously initialized context. -- Viktor.
Re: SMTP session caching
Viktor Dukhovni: > > > > On Mar 22, 2018, at 10:54 AM, Wietse Venema wrote: > > > > Currently, the Postfix SMTP client does a bunch of TLS initialization, > > once per TLS session. > > The expensive stuff for SSL_CTX happens only once in tls_client_init(). > You're only looking at tls_client_start(), which uses a previously > initialized context. Well, each Postfix SMTP client creates SSL_CTX once, then reuses it across multiple TLS sessions. I suppose that tlsproxy can share this object among all sessions that tlsproxy creates for SMTP clients with similar parameters. This is the stuff that gets serialized and passed around between SMTP client, tlsproxy, and that appears in scache lookup keys). This may be non-trivial but it's not rocket science. Wietse
Re: SMTP session caching
> On Mar 22, 2018, at 1:22 PM, Wietse Venema wrote: > > Well, each Postfix SMTP client creates SSL_CTX once, then reuses > it across multiple TLS sessions. I suppose that tlsproxy can share > this object among all sessions that tlsproxy creates for SMTP clients > with similar parameters. This is the stuff that gets serialized and > passed around between SMTP client, tlsproxy, and that appears in > scache lookup keys). Yes, that's what I had in mind. > This may be non-trivial but it's not rocket science. Yes, just a bunch of attention to detail. -- Viktor.
why is smtpd_recipient_restrictions ignored..?
Hi all,
This postfix 2.9.6 from wheezy. I have added to main.cf:
smtpd_recipient_restrictions = check_recipient_access
hash:/etc/postfix/blacklisted_domains, permit_mynetworks,
reject_unauth_destination, permit
and /etc/postfix/blacklisted_domains contains just one line:
mail.ru REJECT
I postmapped the file and restarted postfix.
Alas... postfix is still happily forwarding emails to 1...@mail.ru to my
smarthost.
How can I make sure that this particular postfix instance will DISALLOW
sending ANY email to @mail.ru?
What am I missing?
Thanks in advance!
MJ
Here is my complete main.cf:
# See /usr/share/postfix/main.cf.dist for a commented, more complete version
# Debian specific: Specifying a file name will cause the first
# line of that file to be used as the name. The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no
# appending .domain is the MUA's job.
append_dot_mydomain = no
# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h
readme_directory = no
# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
# to prevent russian spam
smtpd_recipient_restrictions = check_recipient_access
hash:/etc/postfix/blacklisted_domains, permit_mynetworks,
reject_unauth_destination, permit
# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.
myhostname = www.site1.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = www.site1.com, site2.com, localhost.site2.com, localhost,
site3.com
relayhost = outgoing.smarthost.com
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
sender_canonical_maps = hash:/etc/postfix/sender_canonical
Re: why is smtpd_recipient_restrictions ignored..?
> On Mar 22, 2018, at 7:35 PM, mj wrote: > > This postfix 2.9.6 from wheezy. I have added to main.cf: > >> smtpd_recipient_restrictions = check_recipient_access >> hash:/etc/postfix/blacklisted_domains, permit_mynetworks, >> reject_unauth_destination, permit > > and /etc/postfix/blacklisted_domains contains just one line: > >> mail.ru REJECT > > I postmapped the file and restarted postfix. > > Alas... postfix is still happily forwarding emails to 1...@mail.ru to my > smarthost. Almost certainly bounces, which did not come in via SMTP, they are originated locally, when inbound mail from mail.ru is undeliverable, and sent outbound via the smarthost. > How can I make sure that this particular postfix instance will DISALLOW > sending ANY email to @mail.ru? Seems a rather harsh policy, but if you must: transport: mail.ru error:5.1.2 Destination domain blacklisted -- Viktor.
Re: why is smtpd_recipient_restrictions ignored..?
Hi Viktor, On 03/23/2018 12:42 AM, Viktor Dukhovni wrote: Almost certainly bounces, which did not come in via SMTP, they are originated locally, when inbound mail from mail.ru is undeliverable, and sent outbound via the smarthost. Yes, they are originated locally, yes, using a webform that is currently being abused. How can I make sure that this particular postfix instance will DISALLOW sending ANY email to @mail.ru? Seems a rather harsh policy, but if you must: transport: mail.ru error:5.1.2 Destination domain blacklisted It's very harsh, but we'll do it just for the time being, until we have fixed the webform. Your solution works super, thanks a lot! Is there perhaps also another error code we can use, that blackholes the email, instead of politely bouncing it with a "Diagnostic-Code: X-Postfix; Destination domain blacklisted"? MJ
Re: why is smtpd_recipient_restrictions ignored..?
> On Mar 22, 2018, at 7:58 PM, mj wrote: > > On 03/23/2018 12:42 AM, Viktor Dukhovni wrote: >> Almost certainly bounces, which did not come in via SMTP, they are originated >> locally, when inbound mail from mail.ru is undeliverable, and sent outbound >> via the smarthost. > Yes, they are originated locally, yes, using a webform that is currently > being abused. > >>> How can I make sure that this particular postfix instance will DISALLOW >>> sending ANY email to @mail.ru? >> Seems a rather harsh policy, but if you must: >> transport: >> mail.ru error:5.1.2 Destination domain blacklisted > > It's very harsh, but we'll do it just for the time being, until we have fixed > the webform. If you have a compromised webform, DISABLE it, don't try to put on bandaids, or assume that all the abuse will go to just one domain. > Your solution works super, thanks a lot! > > Is there perhaps also another error code we can use, that blackholes the > email, instead of politely bouncing it with a "Diagnostic-Code: X-Postfix; > Destination domain blacklisted"? Yes, but the right answer is turn off the webform until you can replace it with something that is not open to abuse. -- Viktor.
Re: why is smtpd_recipient_restrictions ignored..?
On 03/23/2018 12:58 AM, mj wrote: Is there perhaps also another error code we can use, that blackholes the email, instead of politely bouncing it with a "Diagnostic-Code: X-Postfix; Destination domain blacklisted"? I just found the "discard" option. Thanks you again, Viktor! MJ
Re: why is smtpd_recipient_restrictions ignored..?
On 03/23/2018 01:06 AM, Viktor Dukhovni wrote: Yes, but the right answer is turn off the webform until you can replace it with something that is not open to abuse. We will install a captcha tomorrow. (it's after midnight now) It's also not *that* harmful: they s u b s c r i b e to a wordpress blog, using russian email addresses. Actually: We don't understand what's in it for them... The system then sends a c o n f i r m a t i o n email, that 99% of the time is not clicked. And this all happens to four different .ru domains. Requiring a captcha to s u b s c r i b e will probably get rid of this. MJ
