security level fingerprint does also check peername?
Hi List! for a particular connection, i always received the error message "Server certificate not verified". client was postfix, server was postfix. both as distributed by debian stretch, version 3.1.12-0+deb9u1. i was using the following settings on the smtp-postfix: relayhost=[localhost]:24 smtp_tls_security_level=fingerprint smtp_tls_fingerprint_digest=sha1 smtp_tls_fingerprint_cert_match= i couldn't quite figure out what might be the cause from reading the documentation nor searching "the web". investigating the source code, i now think to have found the cause: file src/smtp/smtp_proto.c near line 1130 is using TLS_MUST_MATCH (defined in tls/tls.h near line 54) which is just a "level>TLS_LEV_ENCRYPT". this causes the "fingerprint" security level to verify the peername in addition to the cert or pkey fingerprint. in my setup, the certificate used by the smtpd-postfix did not include "localhost" as subjAltName (nor as commonName) and therefore the smtp-postfix did report the error "Server certificate not verified". Particular the formulation in the documentation similar to the one in file man/man5/postconf.5 near line 8136 "the server certificate is verified by directly matching its certificate fingerprint" was interpreted by me to mean, that the peername was _not_ checked. This made sense from a security perspective, because after all, as soon as the fingerprint is verified against a trusted store, all other checks do not add security. having told the whole story above, i would now ask this list if: a) someone can adjust the source-code so that security_level=fingerprint does only check the fingerprint and not the peername? -- i think that's the better solution. (however, i do not think i am proficient enough to do this) b) or, i should send in a PATCH for the documentation, editing file proto/postconf.5 accordingly, in order to help others scratching their heads of the same questions? with kind regards, Max signature.asc Description: OpenPGP digital signature
Re: security level fingerprint does also check peername?
On Thu, Dec 19, 2019 at 09:34:49AM +0100, Max-Julian Pogner wrote: > For a particular connection, I always received the error message > "Server certificate not verified". client was postfix, server was > postfix. Both as distributed by debian stretch, version > 3.1.12-0+deb9u1. > I was using the following settings on the smtp-postfix: > relayhost=[localhost]:24 > smtp_tls_security_level=fingerprint > smtp_tls_fingerprint_digest=sha1 > smtp_tls_fingerprint_cert_match= > shown with smtp_tls_loglevel=2> There's no reason to hide the fingerprint, it is likely NOT an exact match. You should test with "posttls-finger -d sha1 ..." > I couldn't quite figure out what might be the cause from reading the > documentation nor searching "the web". Investigating the source code, > I now think to have found the cause: file src/smtp/smtp_proto.c near > line 1130 is using TLS_MUST_MATCH (defined in tls/tls.h near line 54) > which is just a "level>TLS_LEV_ENCRYPT". This causes the "fingerprint" > security level to verify the peername in addition to the cert or pkey > fingerprint. That's not the case. It causes a peer identity check, but the identity in question is the fingerprint, the name is ignored. > In my setup, the certificate used by the smtpd-postfix did not include > "localhost" as subjAltName (nor as commonName) and therefore the > smtp-postfix did report the error "Server certificate not verified". That's not the reason if the security level was indeed fingerprint. > Particular the formulation in the documentation similar to the one in > file man/man5/postconf.5 near line 8136 "the server certificate is > verified by directly matching its certificate fingerprint" was > interpreted by me to mean, that the peername was _not_ checked. Yes, and that's what Postfix does. > a) someone can adjust the source-code so that security_level=fingerprint > does only check the fingerprint and not the peername? -- i think that's > the better solution. No adjustment required, the code already functions as documented. > b) or, i should send in a PATCH for the documentation, editing file > proto/postconf.5 accordingly, in order to help others scratching their > heads of the same questions? No patches required, the code already functions as documented. $ posttls-finger -cd sha1 -l fingerprint "[smtp.dukhovni.org]" 98:40:01:98:0F:75:58:35:92:3B:07:94:CF:58:B9:FA:99:C5:06:F5 posttls-finger: smtp.dukhovni.org[2001:470:1f06:167::2]:25: depth=0 matched end entity public-key sha1 digest=98:40:01:98:0F:75:58:35:92:3B:07:94:CF:58:B9:FA:99:C5:06:F5 posttls-finger: smtp.dukhovni.org[2001:470:1f06:167::2]:25 CommonName mournblade.imrryr.org posttls-finger: smtp.dukhovni.org[2001:470:1f06:167::2]:25: subject_CN=mournblade.imrryr.org, issuer_CN=mournblade.imrryr.org, fingerprint=DF:53:67:E7:87:D8:4E:9A:FF:34:A2:92:36:F8:15:1F:2F:15:82:1B, pkey_fingerprint=98:40:01:98:0F:75:58:35:92:3B:07:94:CF:58:B9:FA:99:C5:06:F5 posttls-finger: Verified TLS connection established to smtp.dukhovni.org[2001:470:1f06:167::2]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 Presto-magic successful fingerprint authentication, despite a mismatched hostname. Tested with: $ postconf mail_version mail_version = 3.4.8 -- Viktor.
Re: Postfix does not evaluate smtpd_recipient_restrictions when email is sent from localhost
Hello Viktor, thank you for suggested solution. I am not advanced postfix admin so it is not easy to understand all and setup it quickly by above links. Do you know some other way how to restrict emails sent from PHP on localhost ? For example can I force PHP to send email through SMTP instead of sendmail with help of some setting in php.ini or other settings ? -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Re: Postfix does not evaluate smtpd_recipient_restrictions when email is sent from localhost
postpeter: > Hello Viktor, > thank you for suggested solution. I am not advanced postfix admin so it is > not easy to understand all and setup it quickly by above links. > > Do you know some other way how to restrict emails sent from PHP on localhost > ? > For example can I force PHP to send email through SMTP instead of sendmail > with help of some setting in php.ini or other settings ? For help with PHP, you may have more luck with a PHP-specific forum. On the Postfix side, someone could add a way to make "sendmail -bs" proxy the caller to the SMTP port, That's can't be the default, because it will fail when Postfix isn't running. Wietse
Re: Postfix does not evaluate smtpd_recipient_restrictions when email is sent from localhost
On Thu, Dec 19, 2019 at 04:31:20AM -0700, postpeter wrote: > Hello Viktor, > thank you for suggested solution. I am not advanced postfix admin so it is > not easy to understand all and setup it quickly by above links. I posted a solution on the Postfix side, that works regardless of the local submission mechanism and does not require changes in PHP, etc. http://postfix.1071664.n5.nabble.com/Postfix-does-not-evaluate-smtpd-recipient-restrictions-when-email-is-sent-from-localhost-td104094.html#a104096 It is less scary than it looks, but if it is nonetheless too intimidating, you'll need to look at SMTP content filters or milters, or solve the problem outside Postfix. -- Viktor.
When a 554 acts like a 471?
I have a case that is odd to me and I can't figure it out. Hopefully
someone here will be able to set me straight. This is on a friend's
system that I am helping to maintain.
My friend somewhat out of the blue decided to start sending mail from
a rented VM server. I hadn't expected and don't think it is really
set up as it should for it. But people do what people do. It is not
set up with DKIM. "inet_interfaces = loopback-only" so it cannot
receive mail and therefore cannot possibly be relaying spam. This was
a clean IP as far as I could tell and my friend has used it for the
last few years. Therefore I know that it has not generated any email
at all other than what my friend has recently decided to send out
personally.
root@ergo:~$ grep 4E7541E092 /var/log/mail.log
Dec 19 13:11:55 ergo postfix/qmgr[2592]: 4E7541E092: from=<[[redacted]]>,
size=4861, nrcpt=2 (queue active)
Dec 19 13:11:55 ergo postfix/smtp[7858]: 4E7541E092:
to=<[[redacted]]@fortboise.org>,
relay=mx.fortboise.org.cust.a.hostedemail.com[216.40.42.4]:25, delay=315407,
delays=315407/0.02/0.14/0, dsn=4.7.1, status=deferred (host
mx.fortboise.org.cust.a.hostedemail.com[216.40.42.4] refused to talk to me: 554
5.7.1 Service unavailable; Client host [93.184.216.34] blocked using
urbl.hostedemail.com; Your IP has been manually blacklisted)
Dec 19 14:21:55 ergo postfix/qmgr[2592]: 4E7541E092: from=<[[redacted]]>,
size=4861, nrcpt=2 (queue active)
Dec 19 14:21:55 ergo postfix/smtp[19888]: 4E7541E092:
to=<[[redacted]]@fortboise.org>,
relay=mx.fortboise.org.cust.a.hostedemail.com[216.40.42.4]:25, delay=319607,
delays=319607/0.02/0.18/0, dsn=4.7.1, status=deferred (host
mx.fortboise.org.cust.a.hostedemail.com[216.40.42.4] refused to talk to me: 554
5.7.1 Service unavailable; Client host [93.184.216.34] blocked using
urbl.hostedemail.com; Your IP has been manually blacklisted)
And the above repeats. I made some obvious redactions and
93.184.216.34 is actually example.com but you can understand me
keeping my friend's information out of my email here. The IP listed
was the IP of my friend's VM originating the mail.
There are currently 15 requests in the queue. Which all appear to be
personal correspondence that my friend typed in. Prolific! They
eventually timeout after, I think, bounce_queue_lifetime as expected.
Here is a sample of the bounce message generated. Which is why I am
involved trying to help.
<[[redacted]]@fortboise.org>: host
mx.fortboise.org.cust.a.hostedemail.com[216.40.42.4]
refused to talk to me: 554 5.7.1 Service unavailable; Client host
[93.184.216.34] blocked using urbl.hostedemail.com; Your IP has been
manually blacklisted
But this confuses me. It appears to me that the message was rejected
at SMTP time with a 554 code. Therefore shouldn't that generate a
bounce message immediately? Why is dsn=4.7.1 being logged there?
Was the actual SMTP rejecting a 554? Or was it a 471? I feel it must
have been a 471 because it is retrying instead of immediately
bouncing. Yet here it is saying it was a 554. In which case why
isn't it bouncing immediately?
I will include some hopefully useful information below.
Thanks!
Bob
root@ergo:~# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
compatibility_level = 2
inet_interfaces = loopback-only
inet_protocols = ipv4
local_header_rewrite_clients = permit_mynetworks, permit_sasl_authenticated
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
masquerade_classes = envelope_sender, header_sender
masquerade_domains = [[redacted]]
masquerade_exceptions = root
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
myhostname = ergo.[[redacted]]
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
defer_unauth_destination
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
This is on the Debian 9 Stretch version of Postfix for which I will
try to avoid the gasp of age from the version number as I don't think
that is the issue here. :-)
Re: When a 554 acts like a 471?
On 12/19/2019 3:54 PM, Bob Proulx wrote: I have a case that is odd to me and I can't figure it out. Hopefully someone here will be able to set me straight. This is on a friend's system that I am helping to maintain. My friend somewhat out of the blue decided to start sending mail from a rented VM server. I hadn't expected and don't think it is really set up as it should for it. But people do what people do. It is not set up with DKIM. "inet_interfaces = loopback-only" so it cannot receive mail and therefore cannot possibly be relaying spam. This was a clean IP as far as I could tell and my friend has used it for the last few years. Therefore I know that it has not generated any email at all other than what my friend has recently decided to send out personally. root@ergo:~$ grep 4E7541E092 /var/log/mail.log Dec 19 13:11:55 ergo postfix/qmgr[2592]: 4E7541E092: from=<[[redacted]]>, size=4861, nrcpt=2 (queue active) Dec 19 13:11:55 ergo postfix/smtp[7858]: 4E7541E092: to=<[[redacted]]@fortboise.org>, relay=mx.fortboise.org.cust.a.hostedemail.com[216.40.42.4]:25, delay=315407, delays=315407/0.02/0.14/0, dsn=4.7.1, status=deferred (host mx.fortboise.org.cust.a.hostedemail.com[216.40.42.4] refused to talk to me: 554 5.7.1 Service unavailable; Client host [93.184.216.34] blocked using urbl.hostedemail.com; Your IP has been manually blacklisted) Dec 19 14:21:55 ergo postfix/qmgr[2592]: 4E7541E092: from=<[[redacted]]>, size=4861, nrcpt=2 (queue active) Dec 19 14:21:55 ergo postfix/smtp[19888]: 4E7541E092: to=<[[redacted]]@fortboise.org>, relay=mx.fortboise.org.cust.a.hostedemail.com[216.40.42.4]:25, delay=319607, delays=319607/0.02/0.18/0, dsn=4.7.1, status=deferred (host mx.fortboise.org.cust.a.hostedemail.com[216.40.42.4] refused to talk to me: 554 5.7.1 Service unavailable; Client host [93.184.216.34] blocked using urbl.hostedemail.com; Your IP has been manually blacklisted) And the above repeats. I made some obvious redactions and 93.184.216.34 is actually example.com but you can understand me keeping my friend's information out of my email here. The IP listed was the IP of my friend's VM originating the mail. There are currently 15 requests in the queue. Which all appear to be personal correspondence that my friend typed in. Prolific! They eventually timeout after, I think, bounce_queue_lifetime as expected. Here is a sample of the bounce message generated. Which is why I am involved trying to help. <[[redacted]]@fortboise.org>: host mx.fortboise.org.cust.a.hostedemail.com[216.40.42.4] refused to talk to me: 554 5.7.1 Service unavailable; Client host [93.184.216.34] blocked using urbl.hostedemail.com; Your IP has been manually blacklisted But this confuses me. It appears to me that the message was rejected at SMTP time with a 554 code. Therefore shouldn't that generate a bounce message immediately? Why is dsn=4.7.1 being logged there? Was the actual SMTP rejecting a 554? Or was it a 471? I feel it must have been a 471 because it is retrying instead of immediately bouncing. Yet here it is saying it was a 554. In which case why isn't it bouncing immediately? The remote server greeted postfix with a 554 code. By default, postfix defers mail when the remote server does this. If you would rather have postfix immediately bounce the mail, see: http://www.postfix.org/postconf.5.html#smtp_skip_5xx_greeting As for why it's being rejected, you'll need to contact the relay postmaster. Looks like the IP has been "manually blacklisted," so one would presume it will need to be manually whitelisted. -- Noel Jones
Re: When a 554 acts like a 471?
Noel Jones wrote: > Bob Proulx wrote: > > But this confuses me. It appears to me that the message was rejected > > at SMTP time with a 554 code. Therefore shouldn't that generate a > > bounce message immediately? Why is dsn=4.7.1 being logged there? > > The remote server greeted postfix with a 554 code. By default, postfix > defers mail when the remote server does this. If you would rather have > postfix immediately bounce the mail, see: > http://www.postfix.org/postconf.5.html#smtp_skip_5xx_greeting "By default, the Postfix SMTP client moves on the next mail exchanger. Specify "smtp_skip_5xx_greeting = no" if Postfix should bounce the mail immediately. Caution: the latter behavior appears to contradict RFC 2821." Hmm... I read through RFC 2821 and it isn't clear to me why 554 Transaction Failed needs to be interpreted as a temporary failure needing a retry. I am sure there is some historical experience of servers using 554 for temporary conditions for which I am missing that makes that behavior the correct default behavior. I thought all of the 5xx codes were non-temporary and should be treated as hard errors. But regardless that is exactly the answer I needed! I am going to set that for my friend's system as I think that is the best setting. > As for why it's being rejected, you'll need to contact the relay postmaster. > Looks like the IP has been "manually blacklisted," so one would presume it > will need to be manually whitelisted. Right. But I have no dillusions about that happening with hostedemail.com which does not seem to be responsive. And actually I would not be surprised if the recipient simply decided to report the messages as spam as a lazy way of saying don't type at me anymore. Thank you for the information! It got me unstuck. :-) Bob
Re: When a 554 acts like a 471?
> On Dec 19, 2019, at 7:00 PM, Bob Proulx wrote: > > "By default, the Postfix SMTP client moves on the next mail > exchanger. Specify "smtp_skip_5xx_greeting = no" if Postfix should > bounce the mail immediately. Caution: the latter behavior appears to > contradict RFC 2821." > > But regardless that is exactly the answer I needed! I am going to set > that for my friend's system as I think that is the best setting. Actually, it may not be. You may end up losing mail when you encounter overloaded servers returning 554. In a bit of synchronicity, just a day or two ago I was corresponding on this very question with Wietse, because there's an effort underway to polish RFC5321 with a goal of making SMTP a "full" Internet Standard (it only takes ~40 years). As part of that, I'd like to see a couple of the murkier bits clarified: * The 552 -> 452 work-around, that should no longer (if ever) be necessary: https://mailarchive.ietf.org/arch/msg/ietf-smtp/fhKAX0Z9frJxUxmZylthJ_LijMM * The semantics of 554 greetings: https://mailarchive.ietf.org/arch/msg/ietf-smtp/NeHzVodzZX6kJFJ7lQhuP6gOpWA -- Viktor.
Re: When a 554 acts like a 471?
Viktor Dukhovni wrote: > > Bob Proulx wrote: > > "By default, the Postfix SMTP client moves on the next mail > > exchanger. Specify "smtp_skip_5xx_greeting = no" if Postfix should > > bounce the mail immediately. Caution: the latter behavior appears to > > contradict RFC 2821." > > > > But regardless that is exactly the answer I needed! I am going to set > > that for my friend's system as I think that is the best setting. > > Actually, it may not be. You may end up losing mail when you > encounter overloaded servers returning 554. In my friend's case an immediate response to a message being sent just now would be better feedback. As opposed to after the bounce timeout occurs some five days later. Email is generally so very reliable these days that when we hear nothing we assume it works. And also that it went straight into the recipient's Junk folder. > In a bit of synchronicity, just a day or two ago I was corresponding > on this very question with Wietse, because there's an effort underway What a coincidence! > to polish RFC5321 with a goal of making SMTP a "full" Internet Standard > (it only takes ~40 years). As part of that, I'd like to see a couple > of the murkier bits clarified: > > * The 552 -> 452 work-around, that should no longer (if ever) > be necessary: > > > https://mailarchive.ietf.org/arch/msg/ietf-smtp/fhKAX0Z9frJxUxmZylthJ_LijMM > > * The semantics of 554 greetings: > > > https://mailarchive.ietf.org/arch/msg/ietf-smtp/NeHzVodzZX6kJFJ7lQhuP6gOpWA And I see I am not the only one to be confused by the use of a 5xx code instead of a 4xx code, or the reverse, for this. The background in the above references was indeed very interesting. It helps to bring me up to speed on the issue. Forty years! Well... We don't want to rush into these things. After all this whole electronic mail thing might just be a fad. :-) Thanks! Bob
