[pfx] Re: XOAUTH2 client
Am 2024-12-22 16:25, schrieb Wietse Venema via Postfix-users:
Alexander Leidinger via Postfix-users:
Am 2024-12-22 01:39, schrieb Peter via Postfix-users:
> On 22/12/24 02:54, Michael Tokarev via Postfix-users wrote:
>>
>> However, there are other mechanisms being developed, for example
>> OAUTH2,
>> which, in terms of Cyrus SASL, does not work with saslauthd at all,
>
> I don't see why it wouldn't.
>
>> so
>> needs direct integration within postfix in a form of plugin.
>
> I don't see why we would need such plugins in Postfix, but if the need
> arises I suppose libgsasl might be an option, if someone wants to put
> the work into it.
>
>> Should such mechanisms be avoided in Postfix?
>
> When it comes to OAUTH the actual SASL interface simply needs to accept
> a bearer token and then works pretty much the same as PLAIN would work.
> Dovecot supports this, I can't speak for whether Cyrus does but I don't
> see why it wouldn't, or why it would be particularly difficult.
>
> That said, OAUTH requires a whole other supporting interface which is
> used to generate the token to begin with, and this is likely beyond the
> scope of the SASL interface (and should remain so). It likely requires
> a web server interface to authenticate the user and either directly
> supply the token or possibly supply the token to a third-party app via
> an API (after authenticating the user via the web interface). Neither
> Postfix nor the SASL backend should have to worry about this aspect of
> OAUTH, though.
I haven't followed the entire discussion, I just have seen this
messages
and the ones after it. As a data point, I use OAUTH2 with postfix /
dovecot since a long time (a year or two/three). The webmail interface
I
use is authenticating against dovecot and uses the same user/oauth
token
for it's authentication against postfix. Works like a charm and
neither
postfix nor dovecot need to worry about how to generate the token,
that's up to the client which talks to them (unfortunately I haven't
found a client for android which supports OAUTH for mail
reading/sending
yet... Aqua Mail is supposed to be able to do that for GMail and
Outlook, but with my own IMAP/SMTP/OIDC servers I do not see/find how
to
achieve this).
The corresponding postfix login looks like this:
Dec 22 15:33:43 xxx postfix/smtpd[34391]: 55E958DF6:
client=xxx[1.2.3.4], sasl_method=XOAUTH2, sasl_username=xxx
That is good news. Do you have essential examples for configuration
that I can include in Postfix documentation?
It's been a while that I did this... I think I got everything listed
here.
This is what I have for postfix (very easy):
---snip---
# grep -i sasl * | grep -v default | grep -v sample | grep smtpd
main.cf:smtpd_sasl_local_domain = $myhostname
main.cf:#smtpd_sasl_auth_enable = yes
main.cf:smtpd_sasl_type = dovecot
main.cf:smtpd_sasl_path = inet:dovecot.server.fqdn:4711
main.cf:smtpd_sasl_security_options = noanonymous, noplaintext
main.cf:smtpd_sasl_tls_security_options = noanonymous
main.cf:smtpd_sasl_authenticated_header = yes
master.cf: -o smtpd_sasl_auth_enable=yes
master.cf: -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
master.cf: -o smtpd_sasl_auth_enable=yes
master.cf: -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
---snip---
The master.cf entries are for submission and smtps.
For completeness I include the non-postfix parts here too...
The dovecot part is a bit more tricky (a lot of trial and error on the
OIDC URLs until it worked) and also depends on the OAUTH / OIDC
provider. In my case the OIDC provider is keycloak:
dovecot conf.d/10-master.conf (excerpt):
---snip---
service auth {
# auth_socket_path points to this userdb socket by default. It's
typically
# used by dovecot-lda, doveadm, possibly imap process, etc. Users that
have
# full permissions to this socket are able to get a list of all
usernames and
# get the results of everyone's userdb lookups.
#
# The default 0666 mode allows anyone to connect to the socket, but
the
# userdb lookups will succeed only if the userdb returns an "uid"
field that
# matches the caller process's UID. Also if caller's uid or gid
matches the
# socket's uid or gid the lookup succeeds. Anything else causes a
failure.
#
# To give the caller full permissions to lookup all users, set the
mode to
# something else than 0666 and Dovecot lets the kernel enforce the
# permissions (e.g. 0777 allows everyone full permissions).
unix_listener auth-userdb {
#mode = 0666
#user =
#group =
}
# Postfix smtp-auth
#unix_listener /var/spool/postfix/private/auth {
# mode = 0666
#}
inet_listener {
port = 4711
}
# Auth process is run as this user.
#user = $default_internal_user
}
---snip---
[pfx] Re: SASL options
Am 2024-12-22 01:39, schrieb Peter via Postfix-users: On 22/12/24 02:54, Michael Tokarev via Postfix-users wrote: However, there are other mechanisms being developed, for example OAUTH2, which, in terms of Cyrus SASL, does not work with saslauthd at all, I don't see why it wouldn't. so needs direct integration within postfix in a form of plugin. I don't see why we would need such plugins in Postfix, but if the need arises I suppose libgsasl might be an option, if someone wants to put the work into it. Should such mechanisms be avoided in Postfix? When it comes to OAUTH the actual SASL interface simply needs to accept a bearer token and then works pretty much the same as PLAIN would work. Dovecot supports this, I can't speak for whether Cyrus does but I don't see why it wouldn't, or why it would be particularly difficult. That said, OAUTH requires a whole other supporting interface which is used to generate the token to begin with, and this is likely beyond the scope of the SASL interface (and should remain so). It likely requires a web server interface to authenticate the user and either directly supply the token or possibly supply the token to a third-party app via an API (after authenticating the user via the web interface). Neither Postfix nor the SASL backend should have to worry about this aspect of OAUTH, though. I haven't followed the entire discussion, I just have seen this messages and the ones after it. As a data point, I use OAUTH2 with postfix / dovecot since a long time (a year or two/three). The webmail interface I use is authenticating against dovecot and uses the same user/oauth token for it's authentication against postfix. Works like a charm and neither postfix nor dovecot need to worry about how to generate the token, that's up to the client which talks to them (unfortunately I haven't found a client for android which supports OAUTH for mail reading/sending yet... Aqua Mail is supposed to be able to do that for GMail and Outlook, but with my own IMAP/SMTP/OIDC servers I do not see/find how to achieve this). The corresponding postfix login looks like this: Dec 22 15:33:43 xxx postfix/smtpd[34391]: 55E958DF6: client=xxx[1.2.3.4], sasl_method=XOAUTH2, sasl_username=xxx Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Documentation Prefix
Am 2024-07-08 06:52, schrieb Ralph Seichter via Postfix-users: * Allen Coates via Postfix-users: I am blocking 2001:db8::/32 (of course); it's the Teredo prefix which I am allowing. I misunderstood the word "these" in your OP, and the subject line only referenced the documentation prefix, but no harm done. I don't have any numbers for connections from Teredo addresses at hand either, but the services I am hosting are not aimed at specific client platforms anyway. Similar to you I am mildly curious if Teredo has any relevance beyond Xbox and a smattering of remaining Windows 10 installations these days. Windows 10 version 1803 and later disable Teredo by default. https://learn.microsoft.com/en-us/windows/whats-new/deprecated-features -> IPv4/6 Transition Technologies As Teredo is a MS thing (invented and propagated by them), I would call it dead. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Handing off via localhost:10025 to spamassassin for scanning failure
Am 2024-06-28 09:01, schrieb Curtis J Blank via Postfix-users: What I am looking for is pretty simple. How to get it to work with "inet_protocols = all" like my existing server is currently set up to do and not be limited to ipv4 only. And it is already set to use 127.0.0.1 so why it is using [::1] instead when the old server uses 127.0.01, that is part of the mystery. The configs are exactly the same yet they operate differently. I want to know why. If you don't know and understand the root cause of something that is not a good position to be in going forward. Good enough is not good enough... Did you already validate (netstat -tnl) that spamassassin listens on both addresses, 127.0.0.1 and ::1? Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: DANE and STS
Am 2024-06-25 08:44, schrieb Jeff Pang via Postfix-users: Hello sorry for the beginner question. how to deploy the following email security features? RFC 7672 SMTP-DANE Outgoing: # validate DANE smtp_dns_support_level = dnssec smtp_tls_security_level = dane # or dane-only (https://www.postfix.org/TLS_README.html) Incoming: - setup DNSSEC for your domain (out of scope here on the postfix list) - publish TLSA records e.g. https://www.sidn.nl/en/news-and-blogs/hands-on-implementing-dane-in-postfix (not everything there is endorsed by several people on this list, specially not the TLS settings in part IV (interoperability vs. "do you really know what you are doing"), what you have to do depends on what you need to protect against (or which checkboxes you have to tick in a report), I provide this link as it gives a good overview about what is involved, not about the particular settings (e.g. you may want to skip large parts of part IV), you may want to use letsencrypt or similar instead of a self-signed cert, you may want to use the PKI cert in the TLSA record (or not), ...). RFC 8461 MTA-STS Incoming (out of scope for the postfix list): - setup of webserver which serves the MTA-STS file - DNS records e.g. https://www.digitalocean.com/community/tutorials/how-to-configure-mta-sts-and-tls-reporting-for-your-domain-using-apache-on-ubuntu-18-04 (info: there exist online services and local tools to investigate TLSA reports) Outgoing: Postfix doesn't come with support for this out of the box. There is https://github.com/Snawoot/postfix-mta-sts-resolver but it has drawbacks (pointed out in the docu). Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: REJECT sending mails to no-reply accounts
Am 2024-06-20 08:21, schrieb Peter via Postfix-users: On 20/06/24 17:47, Tan Mientras via Postfix-users wrote: So many replies! @Ralph Is an automated/unattended email notifying the user about something, providing proper ways of contacting. As this email is not read in any way, rejecting the mail would be a better way to handle than an automatic response. IMHO. A better way would be to set the From: address to someone that will actually respond from your organization (e.g. info@, help@, etc). This implies that the organization / company is willing to spend money on having someone available to actually respond / provide support. For a lot of the use cases I would say even a mail to ticket system gateway is out of the willingness to spend money on. So any technical solution you can propose here, will be way out of the area of interest of those people which will make those decisions. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Troubleshooting roundcube connections to postfix
Am 2024-06-17 06:49, schrieb Paul Schmehl via Postfix-users: On Jun 16, 2024, at 10:30 PM, Peter via Postfix-users wrote: It's likely that roundcube is not configured for TLS and postfix is (as it should be) configured not to offer AUTH until TLS is established. Yes, postfix is configured to use TLS, and no roundcube is not. When I configure roundcube to connect using TLS it can’t even connect to the server. I don’t understand what’s going on with roundcube, but it’s definitely not behavior I would expect. It’s had me pulling my hair out for two days, and I don’t even have any hair. This makes roundcube use STARTTLS on port 587 (submission): ---snip--- $config['smtp_host'] = 'tls://your.smtp.server'; $config['smtp_port'] = 587; ---snip--- Other useful stuff for roundcube: ---snip--- // SMTP username (if required) if you use %u as the username Roundcube // will use the current username for login $config['smtp_user'] = '%u'; // SMTP password (if required) if you use %p as the password Roundcube // will use the current user's password for login $config['smtp_pass'] = '%p'; // Log sent messages to /sendmail.log or to syslog $config['smtp_log'] = true; ---snip--- I’m hoping I have solved the problem. I have roundcube sending mail on port 25 with no auth (all daemons are running on the same server), and it is sending mail. Gmail rejects it, but I’ve altered my spf record to include localhost. I hope once that propagates my problems with be solved. Probably not related to the gmail issue: you may want to remove some headers. I have those header checks to not expose some stuff from roundcube: main.cf: ---snip--- smtp_header_checks = pcre:$config_directory/header_checks ---snip--- $config_directory/header_checks: ---snip--- /^Received: by your\.smtp\.server .*from userid [0-9]+\)/ IGNORE /^Received: from www \(uid 80.*/ IGNORE /^(Received: from your\.roundcube\.server)[^\n]*(.*)/ REPLACE $1 (localhost [127.0.0.1])$2 ---snip--- Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Disable Non Delivery Notifications only for some adresses
23.05.2024 15:38, Kevin Cousin via
Postfix-users пишет:
Le 2024-05-21T22:50:48.000+02:00, Wietse Venema via
Postfix-users a écrit :
Kevin Cousin via Postfix-users:
. . .
Configure a dedicated smtpd servicce in master.cf.
Then use
https://www.postfix.org/postconf.5.html#smtpd_command_filter
to
append NOTIFY=NONE to RCPT TO commands.
For example, to set up a no-bounce service on port 25:
/etc/postfix/master.cf:
:26 .. .. .. .. smtpd
-o { smtpd_command_filter =
pcre:/etc/postfix/no-notify.pcre }
Kevin
Thank you! This is exactly what
I need.
Regards, Alexandr
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: how disable DSN pipe
23.05.2024 19:06, Wietse Venema via Postfix-users пишет: Aleksandr Kolesnikov via Postfix-users: if the user requests a DSN, he receives a delivery message via the ... how to prohibit the sending of such DSN? Perhaps: https://www.postfix.org/DSN_README.html Wietse I may have misunderstood the contents of DSN_README, but I don't need to turn off DSN completely. I need the DSN to not work only for those senders for whom the transport is configured to "resubmit" (pipe). In my case, I was helped by the smtpd_command_filter option, which you pointed out in your recent answer to a similar topic. Thanks for your reply. Regards, Alexandr ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLS for SMTP Outbound -- Only One tlsproxy
Am 2024-05-22 01:22, schrieb Greg Sims via Postfix-users: TLS connection reuse is being used. About 10% of the connections are reused for large volume ISPs. Small volume ISPs do not see connection reuse. I believe this is as expected. I did some testing of our DNS setup. A DNS query using dig is less than 20 msec for both our primary and secondary dns servers in /etc/resolv.conf -- see below. If all else fails: The truth can often be seen on the wire. Make a packet trace which covers the time from "here is the mail you have to send to google" to a successful delivery and inspect it in wireshark. For TLS traffic you need the cert/key in wireshark. Do not only trace the smtp traffic, but all traffic. Inspect what the system is doing (e.g. DNS lookups) and correlate that to the traffic you see (you can change how timestamps are displayed in wireshark). This may indicate where those 25 seconds are spend. This is a steep learning curve if you are not familiar already with interpreting network packets, the smtp protocol, DNS, and wireshark. If those skills are already available, it may lead to detecting the cause of what you see faster than the back and forth with guesses here on the mailinglist. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Is there a way to just quickly deliver "everything" to a file somewhere
Am 2024-04-11 05:39, schrieb Dan Mahoney via Postfix-users: I guess I missed something. — I also want it to null route (or route to a maildir) all *outbound* mail — so we can examine what our ticket system *would* send, is there something in here to do that, or is the above only for inbound? Would this work for your use case? https://serverfault.com/questions/219173/configure-postfix-to-filter-email-into-hold-queue Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: How to set the minimum number of bits for (non-EC) DH key exchange?
Am 2024-03-23 17:17, schrieb Viktor Dukhovni via Postfix-users: PS: As of January 2024, the German BSI has tighten its recommendation for asymmetric algorithms over finite fields to at least 3000 bits (i.e. RSA encryption, RSA signatures and FFDH). With little thought about the opportunistic TLS use-case. I'm not claiming to know what the rationale is, but one possible thought-chain could be: IF there is no MITM, and IF the session is encrypted, then at least use good encrpytion so that an attacker which is only able to listen, is not able to get the content. Also: this is not a specific recommendation for SMTP, it is a generic recommendation for encrypted communication independent from the context it is used in, so there may be no thought at all about opportunistic TLS. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: How to set the minimum number of bits for (non-EC) DH key exchange?
Am 2024-03-23 15:58, schrieb Matthias Nagel via Postfix-users: I wonder whether setting `smtpd_tls_dh1024_param_file` to a custom 2048-bit DH group would help? But from my understanding of the docs that should not be necessary as Postfix 3.8.5 uses a built-in 2048bit group if left empty. Postfix doesn't complain if you configure it this way (I tried). I don't know if it does what you want to do (I have a custom cipher spec I allow). You could install a test-instance and test with nmap: - "nmap -p --script ssl-enum-ciphers ", pay attention to the part "(dh ...)" in the output Do a scan before and after the smtpd_tls_dh1024_param_file change. PS: As of January 2024, the German BSI has tighten its recommendation for asymmetric algorithms over finite fields to at least 3000 bits (i.e. RSA encryption, RSA signatures and FFDH). If this is as a result of an audit, or in preparation of an audit: have a look if it helps to talk with the auditors. Sometimes they are open to arguments (cleartext is allowed, dh 1024 is better than cleartext). If they only look at checkboxes to tick, see the part above or disabling the parts as you suggested (you could increase the smtpd_tls_loglevel to 1 and check over a suitable amount of time if someone is using those ciphers you want to disable before you actually disable them). Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix + Dovecot FreeBSD - a problem
Am 2024-03-12 07:08, schrieb Viktor Dukhovni via Postfix-users: Where is your configuration directory? Are you editing "/etc/postfix/main.cf", or /usr/local/etc/postfix/main.cf? Which "postfix" command are you running, "/usr/sbin/postfix" or "/usr/local/sbin/postfix"? You probably have Postfix both in the base system and from ports. Make sure you're editing the files and using the commands from /usr/local... And that the Postfix that is running (master process, and service daemons) are also the ones from /usr/local/libexec... If there is postfix not only in /usr/local/, but also in /, there is a big problem. There is no postfix supposed to be in / in FreeBSD, it shall only be in /usr/local/. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix + Dovecot FreeBSD - a problem
Am 2024-03-11 05:19, schrieb Glenn Tenney via Postfix-users: (2) Postfix sends to gmail, but does not encrypt when sending. You only tell the receiving side of postfix to set the encrypt level to "may". For the sending side you do not have such a setting: smtp_tls_security_level = ... Maybe you also want to set the TLS protocols for the sending side (sending and receiving side have different config options, "smtp_..." vs "smtpd_..."): smtp_tls_protocols = ... smtp_tls_CApath = /etc/ssl/certs smtp_tls_loglevel = 1 smtpd_tls_cert_file = /usr/local/etc/letsencrypt/live/domain.name/fullchain.pem smtpd_tls_key_file = /usr/local/etc/letsencrypt/live/domain.name/privkey.pem smtpd_tls_protocols = !SSLv2, !SSLv3 smtpd_tls_security_level = may smtpd_use_tls = yes Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Configuration Settings for TLS 1.2 and 1.3 with No Weak Ciphers
Am 2024-02-29 13:46, schrieb Viktor Dukhovni via Postfix-users: On Thu, Feb 29, 2024 at 06:36:09AM -0500, Scott Hollenbeck wrote: > What do you consider weak? All of the anonymous Diffie-Hellman suites with an "F" score. How can eliminate the following: Who's assigning the "F" scores? Nmap is telling this about the scores: ---snip--- Each ciphersuite is shown with a letter grade (A through F) indicating the strength of the connection. The grade is based on the cryptographic strength of the key exchange and of the stream cipher. The message integrity (hash) algorithm choice is not a factor. The output line beginning with Least strength shows the strength of the weakest cipher offered. The scoring is based on the Qualys SSL Labs SSL Server Rating Guide, but does not take protocol support (TLS version) into account, which makes up 30% of the SSL Labs rating. ---snip--- The corresponding Qualys reference is: https://www.ssllabs.com/projects/rating-guide/ Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Configuration Settings for TLS 1.2 and 1.3 with No Weak Ciphers
Am 2024-02-29 10:27, schrieb Viktor Dukhovni via Postfix-users: On Thu, Feb 29, 2024 at 08:59:44AM +0100, Alexander Leidinger via Postfix-users wrote: # grep tls main.cf | grep -vE '^#' smtp_tls_security_level = encrypt smtpd_tls_ask_ccert = yes smtpd_tls_CApath = $smtp_tls_CApath Not generally applicable. I agree. Therefore my comment to not take it blindly. What is good for the partiuclar server where I took this from, may not be suitable for everyone. smtp_tls_mandatory_protocols = !SSLv2 , !SSLv3 , !TLSv1 , !TLSv1.1 smtp_tls_protocols = !SSLv2 , !SSLv3 , !TLSv1 , !TLSv1.1 smtpd_tls_mandatory_protocols = !SSLv2 , !SSLv3 , !TLSv1 , !TLSv1.1 smtpd_tls_protocols = !SSLv2 , !SSLv3 , !TLSv1 , !TLSv1.1 Obsolete syntax. This config has history... tls_random_source = dev:/dev/urandom smtpd_tls_eecdh_grade = auto Best defaulted. smtp_tls_CApath = /etc/ssl/certs Pointless except when the security level is "secure" (or "verify"). You deleted the smtp_tls_policy_maps setting where this may or may not make sense for users... tls_high_cipherlist=ALL:!RSA:!CAMELLIA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SHA1:!SHA256:!SHA384; Not recommended. It disables all non-AEAD ciphers, and aNULL ciphers, which are fine to use. From the OpenSSL man page: ---snip--- aNULL The cipher suites offering no authentication. This is currently the anonymous DH algorithms and anonymous ECDH algorithms. These cipher suites are vulnerable to "man in the middle" attacks and so their use is discouraged. These are excluded from the DEFAULT ciphers, but included in the ALL ciphers. Be careful when building cipherlists out of lower-level primitives such as kDHE or AES as these do overlap with the aNULL ciphers. When in doubt, include !aNULL in your cipherlist. ---snip--- As I said, this should not be taken blindly. Best is to adapt it to the local security guidelines. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Configuration Settings for TLS 1.2 and 1.3 with No Weak Ciphers
TH_AES_128_CBC_SHA (ecdh_x25519) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A | TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A | TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A | TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_128_CCM_8 (rsa 2048) - A | TLS_RSA_WITH_AES_128_CCM (rsa 2048) - A | TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 (rsa 2048) - A | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A | TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A | compressors: | NULL | cipher preference: server | TLSv1.3: | ciphers: | TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A | TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A | TLS_AKE_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A | cipher preference: server |_ least strength: A Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Some TLS connections untrusted in postfix but trusted with posttls-finger
Am 2023-12-01 18:51, schrieb Viktor Dukhovni via Postfix-users:
On Fri, Dec 01, 2023 at 01:52:19PM +0100, Alexander Leidinger wrote:
> No. The problem you're reporting is with name matching. If the
> certificate chain failed to be constructed, that'd be reported instead.
> You'll only see name match errors if the chain construction succeeds,
> but the peer name matching fails.
Great to know. I didn't before you told me. Can I suggest to add this
information to the TLS readme?
That would Postfix documenting OpenSSL library behaviour, and is not
something we can promise as a stable Postfix feature. It just so
happens that OpenSSL first builds a chain, and then verifies various
conditions. Perhaps building the chain first is unavoidable, because
that can bring in name constraints, or other limitations that make the
leaf certififate invalid. So this is unlikely to change, but is not
something Postfix implements or influences.
But it's something postfix uses and it would be possible to tell that at
the time of writing the docs, this is the behavior and that this is
something which is not controlled by postfix but openssl. The info this
would provide is very valuable to understand at which level the problem
happens (in this case the chain was ok, but the hostname didn't match
the expectation). In an ideal world, postfix would even print the info
that this is because of the "secure" policy and that the lower "verify"
policy would have resulted in success.
> The "postls-finger" program will default to "dane" or (absent DANE TLSA
> records) "secure", rather than "may" in order to improve your odds of
> meaningfully testing the remote cert chain.
github is not DNSSEC protected, as such - if I understand the TLS
readme
correctly, postfix will not use DANE. As such I assume, posttls-finger
will
not use DANE too.
Correct. Therefore "posttls-finger" will use the "secure" level, and
its matching policy:
This doesn't match my testing. See below.
The tls policy for github.com was secure in postfix, but I may have
overlooked what posttls-finger is doing if there is no dane record. By
experimantation I now think it is falling back to "verify" in that
case.
Actually "secure", which means that the match strategy is
"nexthop:dot-nexthop" unless you specify additional command-line
arguments to override the match list.
switch (state->level) {
case TLS_LEV_SECURE:
state->match = argv_alloc(2);
while (*argv)
argv_add(state->match, *argv++, ARGV_END);
if (state->match->argc == 0)
argv_add(state->match, "nexthop", "dot-nexthop", ARGV_END);
break;
case TLS_LEV_VERIFY:
state->match = argv_alloc(1);
while (*argv)
argv_add(state->match, *argv++, ARGV_END);
if (state->match->argc == 0)
argv_add(state->match, "hostname", ARGV_END);
break;
case TLS_LEV_FPRINT:
state->dane = tls_dane_alloc();
while (*argv)
tls_dane_add_fpt_digests(state->dane,
state->options.enable_rpk,
*argv++, "", smtp_mode);
break;
...
This would suggest that no -l option should show the same behavior than
"-l secure". This is not the case for the situation I tested (no DNSSEC
for github, as such DANE can not be used, and the default of "secure"
should print "Untrusted" instead of "Verified"):
---snip---
# posttls-finger -c -P /etc/ssl/certs reply.github.com
posttls-finger: in-5.smtp.github.com[140.82.113.31]:25: matched
peername: *.smtp.github.com
posttls-finger: in-5.smtp.github.com[140.82.113.31]:25:
subject_CN=*.smtp.github.com, issuer_CN=DigiCert TLS RSA SHA256 2020
CA1,
fingerprint=4B:7B:90:8B:F3:F3:28:AE:36:C2:D4:04:91:07:32:90:A5:EC:39:54:10:C3:40:E0:93:D0:3B:43:36:A0:45:1B,
pkey_fingerprint=8E:41:0A:98:75:E4:25:83:7A:02:32:67:6A:30:A4:13:7C:E3:C7:61:16:99:E9:CF:3B:0F:58:02:72:FA:F3:48
posttls-finger: Verified TLS connection established to
in-5.smtp.github.com[140.82.113.31]: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
# posttls-finger -c -l secure -P /etc/ssl/certs reply.github.com
posttls-finger: server certificate verification failed for
in-7.smtp.github.com[140.82.114.31]:25: num=62:hostname mismatch
posttls-finger: in-7.smtp.github.com[140.82.114.31]:25:
subject_CN=*.smtp.github.com, issuer_CN=DigiCert TLS RSA SHA256 2020
CA1,
fingerprint=4B:7B:90:8B:F3:F3:28:AE:36:C2:D4:04:91:07:32:90:A5:EC:39:54:10:C3:40:E0:93:D0:3B:43:36:A0:45:1B,
pkey_fingerprint=8E:41:0A:98:75:E4:25:83:7A:02:32:67:6A:30:A4:13:7C:E3:C7:61:16:99:E9:
[pfx] Re: Some TLS connections untrusted in postfix but trusted with posttls-finger
Am 2023-12-01 13:44, schrieb Wietse Venema: Alexander Leidinger: Am 2023-11-30 16:53, schrieb Wietse Venema via Postfix-users: > Alexander Leidinger via Postfix-users: >> What is wrong here that [tlsproxy] doesn't establish a trusted >> connection >> to the github mailservers when posttls-finger is able to do that with >> the same cert store? > > Because there are differences between tlsproxy and posttls-finger. > > 1) Different executable files may be subject to different SeLinux, > AppArmor etc. policies. This is FreeBSD, no different policies. > 2) Different privileges: tlsproxy runs as the "postfix" user, > posttls-finger as "root". ... > 3) Different certificate stores, when tlsproxy may runs chrooted, > and posttls-finger does not. As Viktor poointed out 4) Diferent certificate match expectations. May I suggest to add a note or two to the man page of posttls-finger in the sense that posttls-finger doesn't look at the postfix config and is standalone, and that if configure with TLS support the default is (as documented) "-l dane" but that this fall back to "-l verify" (at least according to my experiment) if the domein is not DNSSEC enabled? I also suggest to add a note to the TLS readme that if the policy is secure and the chain validates, but the hostname doesn't match what postfix expects (it would also be good if it would print the hostname it expects in the default log level), that it prints the hostname mismatch error. It would also be nice if it is documented what it prints when the certificate chain doesn't validate in that case. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Some TLS connections untrusted in postfix but trusted with posttls-finger
Am 2023-12-01 12:40, schrieb Byung-Hee HWANG via Postfix-users: Alexander Leidinger via Postfix-users writes: Am 2023-12-01 12:08, schrieb Byung-Hee HWANG via Postfix-users: ... Nov 30 11:31:48 mailgate postfix/tlsproxy[175]: server certificate verification failed for in-8.smtp.github.com[140.82.114.32]:25: num=62:hostname mismatch ... Maybe you check? root@yw-1204:/etc/postfix# postconf -n | grep CAfile smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt # postconf -n | grep tls_CA smtp_tls_CApath = /etc/ssl/certs smtpd_tls_CApath = /etc/ssl/certs My test logshot: Dec 1 11:33:07 yw-1204 postfix/pickup[57397]: 7AB329A3: uid=1000 from= Dec 1 11:33:07 yw-1204 postfix/cleanup[59196]: 7AB329A3: message-id=<20231201113307.7ab32...@yw-1204.doraji.xyz> Dec 1 11:33:07 yw-1204 opendkim[637]: RFC2822-From: Byung-Hee HWANG Dec 1 11:33:07 yw-1204 opendkim[637]: RFC2821-From: soyeo...@yw.doraji.xyz Dec 1 11:33:07 yw-1204 opendkim[637]: RFC2821-To: devn...@reply.github.com Dec 1 11:33:07 yw-1204 opendkim[637]: 7AB329A3: DKIM-Signature field added (s=yw-1204-doraji-xyz, d=doraji.xyz) Dec 1 11:33:07 yw-1204 postfix/qmgr[54966]: 7AB329A3: from=, size=394, nrcpt=1 (queue active) Dec 1 11:33:08 yw-1204 postfix/smtp[59204]: Trusted TLS connection established to in-5.smtp.github.com[140.82.113.31]: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 Dec 1 11:33:09 yw-1204 postfix/smtp[59204]: 7AB329A3: to=, relay=in-5.smtp.github.com[140.82.113.31]:25, delay=1.6, delays=0.01/0.01/1.2/0.34, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as BE91F5E034E) Dec 1 11:33:09 yw-1204 postfix/qmgr[54966]: 7AB329A3: removed Actually i have no problem. So Again you need to do double check CAfile things in main.cf ;;; No, it's a pure security policy thing and an overlooked line in the mysql tls policy table. The policy "secure" (and I assume "dane-only") doesn't work, as github is not using DNSSEC. Valid policies which make this work are "verify", "may" and I assume "dane" (if you have "smtp_tls_security_level = may" or verify resp. "smtpd_tls_security_level = may" or verify). Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Some TLS connections untrusted in postfix but trusted with posttls-finger
Am 2023-12-01 11:22, schrieb Viktor Dukhovni via Postfix-users: On Fri, Dec 01, 2023 at 09:53:25AM +0100, Alexander Leidinger via Postfix-users wrote: > > Why should it expect reply.github.com? > > Because that name is securely known from the recipient address. Because, whether you're willing to understand the point or prefer to "dig in", verifying a certificate against an attacker-supplied name is pointless. You gain no security by checking attacker-supplied names. You want to deposit a bunch of cash into your bank account, I meet you in a bar wearing a name tag that says I'm the manager of your bank, you give me a hefty sum of money in cash to deposit into your account... This is not a problem which can be solved in a purely technical manner for SMTP in an automated way (= deploy this new MTA and it works). It needs an incompatible redesign of sending "email" with the buy-in of the world. I'm well aware of that. If then someone send mails to alexan...@leidinger.net, why should it match the hostname against leidinger.net? Because that's the only name worth verifying, otherwise skip the potential delivery issues and don't verify. My MX is mailgate.leidinger.net, it has a SAN with mailgate.leidinger.net, and I expect the sending MTA to match the hostname in the MX against the SAN of the cert. An active attacker can replace "your" MX with "send.money.now" for which he has a handy certificate from Let's Encrypt. Yes. I'm fully aware of that. TLS in SMTP can not make sure it delivers to the person I intended it to be delivered to. It also doesn't make sure nobody else than the recipient is able to read the mail. The same way a snail mail can not prevent someone from intercepting the envelope, and having a look inside. But like a double-envelope in snail mail, TLS is able to prevent a bystander (e.g. my ISP) besides the post-delivery-person to have a peek at what is written (like the difference between a postcard and a letter in an envelope). > The MX hostname is typically obtained via an insecure (subjet to MiTM > tampering) DNS lookup, so you lose all security when validating > certificates against the payloads of MX records. You (and the link) are talking about trust. Really about the futility of going through the motions of verifying certificates in the absence of trustworthy "reference identifiers". An attacker has to go through a lot of hops to break DNSSEC to make a man in the middle attack (yes, github is not DNSSEC protected, leidinger.net isn't either). There are cases where it is good enough for my use case. For my use case with github, I do not depend on validating the authenticity of the remote host. I'm even not depending on the privacy feature of TLS in terms of github. I talk about the technical operation of establishing a TLS connection and verifying the certificate. You can go through the motions if you want, but it won't achieve any security goals. Not with github. I fully agree. With github it was about the technical issues I wanted to understand and solve (and it is solved now, see below). The technical problem I have is that postfix seems to use parts of the cert store (it validates the MX of FreeBSD, but not the MX of github), whereas posttls-finger uses the complete cert store. No. The problem you're reporting is with name matching. If the certificate chain failed to be constructed, that'd be reported instead. You'll only see name match errors if the chain construction succeeds, but the peer name matching fails. Great to know. I didn't before you told me. Can I suggest to add this information to the TLS readme? As answered to Wietse, the cert store is readable no permission problem, no user access problem, no security polcies, no chroot. As evidenced by the fact that you got a name matching problem. He didn't tell that posttls-finger uses a different validation policy than postfix. The "postls-finger" program will default to "dane" or (absent DANE TLSA records) "secure", rather than "may" in order to improve your odds of meaningfully testing the remote cert chain. github is not DNSSEC protected, as such - if I understand the TLS readme correctly, postfix will not use DANE. As such I assume, posttls-finger will not use DANE too. The tls policy for github.com was secure in postfix, but I may have overlooked what posttls-finger is doing if there is no dane record. By experimantation I now think it is falling back to "verify" in that case. At least the output between "-l may", "-l secure" and "-l verify" lead me to this assumption. May I suggest to add a comment to the man page of posttls-finger in this regard? Otherwise, it uses default settings, but you have a policy
[pfx] Re: Some TLS connections untrusted in postfix but trusted with posttls-finger
Am 2023-12-01 12:08, schrieb Byung-Hee HWANG via Postfix-users: ... Nov 30 11:31:48 mailgate postfix/tlsproxy[175]: server certificate verification failed for in-8.smtp.github.com[140.82.114.32]:25: num=62:hostname mismatch ... Maybe you check? root@yw-1204:/etc/postfix# postconf -n | grep CAfile smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt # postconf -n | grep tls_CA smtp_tls_CApath = /etc/ssl/certs smtpd_tls_CApath = /etc/ssl/certs Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Some TLS connections untrusted in postfix but trusted with posttls-finger
Am 2023-12-01 09:34, schrieb Tom Hendrikx via Postfix-users: On 01-12-2023 08:59, Alexander Leidinger via Postfix-users wrote: Am 2023-11-30 16:53, schrieb Wietse Venema via Postfix-users: Alexander Leidinger via Postfix-users: What is wrong here that [tlsproxy] doesn't establish a trusted connection to the github mailservers when posttls-finger is able to do that with the same cert store? Because there are differences between tlsproxy and posttls-finger. 1) Different executable files may be subject to different SeLinux, AppArmor etc. policies. This is FreeBSD, no different policies. 2) Different privileges: tlsproxy runs as the "postfix" user, posttls-finger as "root". Ok. The cert store permissions are OK. Any ordinary user is able to read it. posttls-finger as any other user (incl. postfix) produces the same output. With -P it verifies the cert, without it it doesn't. So still the question why the same configured cert store (posttls-finger + postfix + @FreeBSD.org + @reply.github.com) works for sending mail to FreeBSD.org but not to github.com. 3) Different certificate stores, when tlsproxy may runs chrooted, and posttls-finger does not. No chroot-difference between both. This runs in a FreeBSD jail (like a container or a Solaris zone) and I was logged into this container, so both have seen the same filesystem content. There still seems to be a disconnect in communication here, as you didn't quote Viktors response on 'smtp_tls_policy_maps', which seems to be the key issue here. The policy in your connection to github seems to be 'verify' or higher. I was simply not fast enough for you to answer to his mail. :) I just answered. In short: no this is not the key issue here. I don't care right now if my mail to github is deliverd. My point right now is the TLS communication only. See my answer to his mail for the details. Maybe you could test again with an empty 'smtp_tls_policy_maps' parameter in postfix config, or show all values in your policy map explicitly (which might be difficult due to mysql usage)? Short: I overlooked a line in the DB. But right now the delivery is not my concern. I could easily change the DB but will let it as it is to not need to change something somewhere to test the TLS part against github. More in my other answer. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Some TLS connections untrusted in postfix but trusted with posttls-finger
Am 2023-11-30 18:36, schrieb Viktor Dukhovni via Postfix-users: On Thu, Nov 30, 2023 at 03:37:02PM +0100, Alexander Leidinger via Postfix-users wrote: > > Nov 30 11:18:40 mailgate postfix/tlsproxy[98300]: server certificate > > verification failed for in-9.smtp.github.com[140.82.112.31]:25: > > num=62:hostname mismatch > > That is the error. Indeed that's the issue. The SANs in the certificate don't match the name matching settings for this destination. > The hostname your TLS configuration is probably expecting for that > connection is reply.github.com, but that's apparently just a mail > domain, not a hostname, and the machines acting as MXs for it don't use > a certificate with that name. Why should it expect reply.github.com? Because that name is securely known from the recipient address. But it doesn't matter. If I use a commercial spam filter solution in the cloud, I would have to set my MX to a hostname I can't control and which is not in any relation to my own domain name. If then someone send mails to alexan...@leidinger.net, why should it match the hostname against leidinger.net? My MX is mailgate.leidinger.net, it has a SAN with mailgate.leidinger.net, and I expect the sending MTA to match the hostname in the MX against the SAN of the cert. I do not expect it to match against leidinger.net. If I set the MX of leidinger.net to smtp.google.com, I expect the delivering MTA to check the SAN against smtp.google.com, and not against leidinger.net. How else can you use a Google workspace offering as a MX for your own domain (https://support.google.com/a/answer/9222085?hl=en#zippy=%2Cstep-sign-in-to-your-domain-host%2Cstep-add-the-mx-record)? The MX record lists in-9.smtp.github.com as a MX, http://www.postfix.org/TLS_README.html#client_tls_limits The MX hostname is typically obtained via an insecure (subjet to MiTM tampering) DNS lookup, so you lose all security when validating certificates against the payloads of MX records. You (and the link) are talking about trust. I talk about the technical operation of establishing a TLS connection and verifying the certificate. The validation itself has nothing to do with trust. The technical operation takes a hostname to validate the SAN in the cert against, and a cert-chain to validate it against. Trust is orthogonal to this. I agree with all what is written in the link and what you said about insecure (if no DNSSEC is used), but this is trust, not technical validation. The technical problem I have is that postfix seems to use parts of the cert store (it validates the MX of FreeBSD, but not the MX of github), whereas posttls-finger uses the complete cert store. As answered to Wietse, the cert store is readable no permission problem, no user access problem, no security polcies, no chroot. He didn't tell that posttls-finger uses a different validation policy than postfix. If I understand it correctly: if both have the same access to the cert store and the network, they should produce the same result (valid or not valid). They don't. I want to solve this technical problem and let them both agree, that the cert is valid (which it is, the SAN of the MX of github has *.smtp.github.com, and this is a match from a certificate validation point of view with the hostname the MX presents). This has nothing to do with the email address I want to deliver to this server. See above. You're missing the point. I agree that we are talking about 2 different things. Please tell me what is wrong about: - the MX of domain A.c points to a.B.c - a sending MTA has to take a.B.c and match it against the SAN the server a.B.c provides (ignoring details of doing a reverse lookup and resolving the resulting IP and validating that too) In HTTP the name to match against what is provided by the user in the URL, in SMTP it is the MX, as the domain part of the email address is not at all significant for the name of the MX (see above the Google workspace example). So there is a mismatch between postfix and postls-finger on a TLS connection level which to my understanding shall not happen. No, there's a mismatch between the configuration of your Postfix SMTP client and what you posttls-finger was asked to do. That's the reason why I come her and ask what I do wrong. I agree that there is a difference between the operation of both. I want to have both to agree. What do I have to do to the MTA, to let it agree with the result of posttls-finger? Where shall I look for which problem? Which part of my config is affecting that and should check for X or provide for inspection? What can I do to drill down more? Tracing which part of postfix (ktrace (like strace), dtrace... whatever), looking for what action/access/...? smtp_tls_policy_maps = hash:/my/tls_policy, mysql:/my/tls-policy.cf This must be matching "repl
[pfx] Re: Some TLS connections untrusted in postfix but trusted with posttls-finger
Am 2023-11-30 16:53, schrieb Wietse Venema via Postfix-users: Alexander Leidinger via Postfix-users: What is wrong here that [tlsproxy] doesn't establish a trusted connection to the github mailservers when posttls-finger is able to do that with the same cert store? Because there are differences between tlsproxy and posttls-finger. 1) Different executable files may be subject to different SeLinux, AppArmor etc. policies. This is FreeBSD, no different policies. 2) Different privileges: tlsproxy runs as the "postfix" user, posttls-finger as "root". Ok. The cert store permissions are OK. Any ordinary user is able to read it. posttls-finger as any other user (incl. postfix) produces the same output. With -P it verifies the cert, without it it doesn't. So still the question why the same configured cert store (posttls-finger + postfix + @FreeBSD.org + @reply.github.com) works for sending mail to FreeBSD.org but not to github.com. 3) Different certificate stores, when tlsproxy may runs chrooted, and posttls-finger does not. No chroot-difference between both. This runs in a FreeBSD jail (like a container or a Solaris zone) and I was logged into this container, so both have seen the same filesystem content. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Some TLS connections untrusted in postfix but trusted with posttls-finger
Am 2023-11-30 15:03, schrieb Bill Cole via Postfix-users: On 2023-11-30 at 08:03:09 UTC-0500 (Thu, 30 Nov 2023 14:03:09 +0100) Alexander Leidinger via Postfix-users is rumored to have said: My main.cf contains the same certs-path for smtp and smtpd TLS connections: ---snip--- # grep CApath main.cf smtp_tls_CApath = /etc/ssl/certs smtpd_tls_CApath = /etc/ssl/certs ---snip--- What I see in the failure case is: ---snip--- Nov 30 11:18:40 mailgate postfix/tlsproxy[98300]: CONNECT to [140.82.112.31]:25 Nov 30 11:18:40 mailgate postfix/tlsproxy[98300]: server certificate verification failed for in-9.smtp.github.com[140.82.112.31]:25: num=62:hostname mismatch That is the error. The hostname your TLS configuration is probably expecting for that connection is reply.github.com, but that's apparently just a mail domain, not a hostname, and the machines acting as MXs for it don't use a certificate with that name. Why should it expect reply.github.com? The MX record lists in-9.smtp.github.com as a MX, postfix is connecting to it, the cert has *.smtp.github.com, and as such it should match the hostname. This has nothing to do with the email address I want to deliver to this server. I can let point the MX of leidinger.net to generic.imaginary.mail.provider.com, and as long as this provider has a valid cert for itself, the TLS connection should verify, no matter if this mail server acceps mail for leidinger.net or not. The same is true for the working connection to freebsd.org. It is connecting to mx1.freebsd.org which is not at all the same as the maildomain @freebsd.org I used, and it doesn't fail. You can probably make it work for this case with suitable special-casing in your configuration, but your configuration is a total mystery to us... Also, I wouldn't consider it a worthwhile effort for most systems, but that's your call for your environment. You removed the part where posttls-finger is able to verify the connection if I add -P /etc/ssl/cert, but postfix isn't, and it is using the same cert store. So there is a mismatch between postfix and postls-finger on a TLS connection level which to my understanding shall not happen. The config: ---snip--- # postconf -n | grep tls smtp_tls_CApath = /etc/ssl/certs smtp_tls_chain_files = $smtpd_tls_chain_files smtp_tls_connection_reuse = yes smtp_tls_fingerprint_digest = sha256 smtp_tls_mandatory_ciphers = high smtp_tls_mandatory_protocols = !SSLv2 , !SSLv3 , !TLSv1 , !TLSv1.1 smtp_tls_note_starttls_offer = yes smtp_tls_policy_maps = hash:/my/tls_policy, mysql:/my/tls-policy.cf smtp_tls_protocols = !SSLv2, !SSLv3 smtp_tls_security_level = may smtp_tls_session_cache_database = btree:$data_directory/smtp_scache smtp_tls_session_cache_timeout = 36000s smtpd_tls_CApath = /etc/ssl/certs smtpd_tls_ask_ccert = yes smtpd_tls_auth_only = yes smtpd_tls_chain_files = /my/keys_and_chain_files smtpd_tls_dh1024_param_file = /my/dh_2048.pem smtpd_tls_dh512_param_file = /my/dh_512.pem smtpd_tls_eecdh_grade = auto smtpd_tls_mandatory_ciphers = high smtpd_tls_mandatory_exclude_ciphers = export, weak, medium, low, SEED, RSA, CAMELIA, aNULL, eNULL, 3DES, MD5, EXP, PSK, SRP, DSS, RC4, SHA1 smtpd_tls_mandatory_protocols = !SSLv2 , !SSLv3 , !TLSv1 , !TLSv1.1 smtpd_tls_protocols = !SSLv2, !SSLv3 , !TLSv1 , !TLSv1.1 smtpd_tls_received_header = yes smtpd_tls_security_level = may smtpd_tls_session_cache_database = btree:/my/smtpd_scache smtpd_tls_session_cache_timeout = 36000s tls_high_cipherlist = ALL:!RSA:!CAMELLIA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SHA1:!SHA256:!SHA384; tls_preempt_cipherlist = yes tls_random_source = dev:/dev/urandom tls_ssl_options = NO_COMPRESSION ---snip--- And the tls policy map contains nothing for github. This is with postfix 3.8.3. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Some TLS connections untrusted in postfix but trusted with posttls-finger
verification failed for in-10.smtp.github.com[140.82.112.32]:25: untrusted issuer /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA posttls-finger: in-10.smtp.github.com[140.82.112.32]:25: subject_CN=*.smtp.github.com, issuer_CN=DigiCert TLS RSA SHA256 2020 CA1, fingerprint=4B:7B:90:8B:F3:F3:28:AE:36:C2:D4:04:91:07:32:90:A5:EC:39:54:10:C3:40:E0:93:D0:3B:43:36:A0:45:1B, pkey_fingerprint=8E:41:0A:98:75:E4:25:83:7A:02:32:67:6A:30:A4:13:7C:E3:C7:61:16:99:E9:CF:3B:0F:58:02:72:FA:F3:48 posttls-finger: Untrusted TLS connection established to in-10.smtp.github.com[140.82.112.32]: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 # posttls-finger -c -P /etc/ssl/certs reply.github.com posttls-finger: in-7.smtp.github.com[140.82.114.31]:25: matched peername: *.smtp.github.com posttls-finger: in-7.smtp.github.com[140.82.114.31]:25: subject_CN=*.smtp.github.com, issuer_CN=DigiCert TLS RSA SHA256 2020 CA1, fingerprint=4B:7B:90:8B:F3:F3:28:AE:36:C2:D4:04:91:07:32:90:A5:EC:39:54:10:C3:40:E0:93:D0:3B:43:36:A0:45:1B, pkey_fingerprint=8E:41:0A:98:75:E4:25:83:7A:02:32:67:6A:30:A4:13:7C:E3:C7:61:16:99:E9:CF:3B:0F:58:02:72:FA:F3:48 posttls-finger: Verified TLS connection established to in-7.smtp.github.com[140.82.114.31]: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 ---snip--- What is wrong here that postfix doesn't establish a trusted connection to the github mailservers when posttls-finger is able to do that with the same cert store? Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: check sender trouble
18.11.2023 17:32, Matus UHLAR -
fantomas via Postfix-users пишет:
On
18.11.23 07:30, Alexander Kolesnikov via Postfix-users wrote:
192.168.250.35:27 inet n - n
- - smtpd -o syslog_name=postfix/$service_name -o
smtpd_delay_reject=no -o
smtpd_sender_restrictions=pcre:/etc/postfix/senders_cgp.pcre,reject_non_fqdn_sender,reject
telnet 192.168.250.35 27
Trying 192.168.250.35...
Connected to hak.vdk.ru.
Escape character is '^]'.
220 hak.vdk.ru ESMTP Postfix
mail from: w.w
250 2.1.0 Ok
rset
250 2.0.0 Ok
mail from: w@w
554 5.7.1 : Sender address rejected: Access denied
I'm sorry, but I haven't fixed the
problem. What do I need to do so
that the postfix does not accept messages with an incomplete
sender
address (without the domain part)?
I guess you are trying to connect from 192.168.250.35 which is
considered local: http://www.postfix.org/postconf.5.html#local_header_rewrite_clients
so the append_at_myorigin applies.
I have configured in main.cf
local_header_rewrite_clients = inline:{ 192.168.250.25=ok }
inet_interfaces = 127.0.0.1
and connected with a telnet from the address 192.168.250.14. And
the postfix still accepts messages from the sender without the
domain part.
Did I set up local_header_rewrite_clients and inet_interfaces
correctly?
Regards, Alexander
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] check sender trouble
postconf -n
alias_database = lmdb:/etc/postfix/aliases
alias_maps = lmdb:/etc/postfix/aliases
append_at_myorigin = no
append_dot_mydomain = no
command_directory = /usr/sbin
compatibility_level = 3.8
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
default_database_type = lmdb
default_transport = smtp
header_checks = pcre:/etc/postfix/header_checks.pcre
html_directory = /etc/postfix/html
inet_protocols = ipv4
mail_owner = postfix
mailq_path = /usr/libexec/postfix/mailq
manpage_directory = /usr/local/man
maximal_backoff_time = 300s
meta_directory = /etc/postfix
minimal_backoff_time = 300s
multi_instance_directories =
multi_instance_enable = yes
multi_instance_wrapper = ${command_directory}/postmulti -p --
mydestination = hak.vdk.ru
myhostname = hak.vdk.ru
mynetworks = 127.0.0.0/8
newaliases_path = /usr/libexec/postfix/newaliases
queue_directory = /var/spool/postfix
readme_directory = /etc/postfix/READMES
relayhost = [192.168.250.14]
sample_directory = /etc/postfix
sendmail_path = /usr/libexec/postfix/sendmail
setgid_group = postdrop
shlib_directory = no
smtpd_recipient_restrictions = lmdb:/etc/postfix/recipient_check
unknown_local_recipient_reject_code = 550
postconf -M
smtp inet n - n - - smtpd
dnsblogunix - - n - 0 dnsblog
tlsproxy unix - - n - 0 tlsproxy -o tlsproxy_client_security_level=none -o tlsproxy_use_tls=yes -o tlsproxy_tls_loglevel=5
192.168.250.35:27 inet n - n - - smtpd -o syslog_name=postfix/$service_name -o smtpd_delay_reject=no -o smtpd_sender_restrictions=pcre:/etc/postfix/senders_cgp.pcre,reject_non_fqdn_sender,reject
pickup unix n - n 60 1 pickup
cleanupunix n - n - 0 cleanup
qmgr unix n - n 300 1 qmgr
tlsmgr unix - - n 1000? 1 tlsmgr
rewriteunix - - n - - trivial-rewrite
bounce unix - - n - 0 bounce
defer unix - - n - 0 bounce
trace unix - - n - 0 bounce
verify unix - - n - 1 verify
flush unix n - n 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - n - - smtp -o smtp_bind_address=192.168.250.35
smtp-2 unix - - n - - smtp -o smtp_bind_address=192.168.250.0
relay unix - - n - - smtp -o syslog_name=postfix/$service_name
showq unix n - n - - showq
error unix - - n - - error -o daemon_timeout=300
retry unix - - n - - error -o daemon_timeout=300
discardunix - - n - - discard
local unix - n n - - local
virtualunix - n n - - virtual
lmtp unix - - n - - lmtp
anvil unix - - n - 1 anvil
scache unix - - n - 1 scache
postlogunix-dgram n - n - 1 postlogd
telnet 192.168.250.35 27
Trying 192.168.250.35...
Connected to hak.vdk.ru.
Escape character is '^]'.
220 hak.vdk.ru ESMTP Postfix
mail from: w.w
250 2.1.0 Ok
rset
250 2.0.0 Ok
mail from: w@w
554 5.7.1 : Sender address rejected: Access denied
rset
250 2.0.0 Ok
mail from: w@
501 5.1.7 Bad sender address syntax
rset
250 2.0.0 Ok
mail from: w.w
250 2.1.0 Ok
quit
221 2.0.0 Bye
Connection closed by foreign host.
I'm sorry, but I haven't fixed the problem. What do I need to
do so that the postfix does not accept messages with an incomplete
sender address (without the domain part)?
Regards, Alexander
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Send every mail to external antispam gateway
Hello, I'm looking for a solution to send every mail, also from one internal mailbox to another internal mailbox, to an external server which check the mails. The external server will send every mail back to postfix. Also every external mail will only come from this external server. Mails from the external server should be "clean" and stored to the mailbox. Is this possible? Best regards, Alex ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
Re: SMTPD delay rejects evaluation]
On 29-12-2021 11:13, Matus UHLAR - fantomas wrote: - With smtpd_delay_reject=no, Postfix will log a DNSBL 'reject' in smtpd_client_restrictions without any sender or recipient information. That makes it difficult to answer questions about "missing" email. And when SASL is used with delays set to no, when the first reject happens, client is out so the very much wanted authentication info is delayed and that decreases the guessing possibilities extremely low and makes the attack close to impossible to ever succeed with proper RBL updating. fail2ban can to this. you can fill your local dnsbl with that, although I prefer blocking connection from those IPs at firewall level. I am guessing you use fail2ban to block those IP's at firewall level. So fail2ban is not a bad place to start in any case, it can take care of both.
Conditional relayhost based on message size
Hello, My goal is to conditionally select the relayhost based on the total size of the outgoing message. The rationale is that I'm using Amazon AWS SES for the most part. Alas, SES only accepts messages up to 10 MB in size (this includes images and attachments that are part of the message), and when the outgoing message exceeds that size, it will be bounced. Any tips for filters or tools that would help me define another relayhost based on the outgoing message size would be greatly appreciated! Alex
Re: Architectural question for handing submission mail to a smarthost
Wietse asked: > What should happen with local submissions via /usr/sbin/sendmail? Thanks, I forgot about those, they too should go to the separate smarthost. Your follow-up message passing options to pickup(8) would seem to take care of that. > /etc/postfix/master.cf > submission .. .. .. .. .. .. smtpd >-o ...usual submission options... >-o content_filter=smtp:filterhost.example >-o receive_override_options=no_header_body_checks Intriguing. To indulge my desire to better understand the internals, what is the difference between using -o content_filter=smtp:filterhost.example vs using -o relayhost=filterhost.example -o local_transport=smtp:filterhost.example ? Naively reading the documentation, I expect either case should cause all messages to go via SMTP to filterhost.example, but the latter approach did not work for me, and I'm curious to understand why... In appreciation, Alex
Architectural question for handing submission mail to a smarthost
Hello, I seek advice. For mail received on port 25 for my domain, the usual local transport should be used (as accomplished with mydestination=mydomain), but for mail submitted by authorized users on port 587, I want all such mail (even for recipients@mydomain) to get sent via SMTP to a separate smarthost for additional filtering. In other words, for port 587 I essentially want mydestination to be blank. Can this be easily accomplished within a single postfix instance (using "-o options" within master.cf), or is this a situation where having multiple postfix personalities (multiple instances using postmulti) is the way to go? Thanks! Alex
Appropriate mydestination/local_transport setting for a split server config?
Some of my users want to migrate to a cloud mail provider (with the same mail domain name), while others want to stay on my on-premise postfix server. Thus I seek to set up a "split server config", essentially using the cloud server as a smarthost to be both an outbound and inbound gateway. A complication is that the users who stay on-premise will continue submitting their mail to the on-premise server, but the on-premise server has no way of knowing which domain users are provisioned at the cloud mail provider, thus the on-premise server must hand all submitted mail (even for its own domain) to the cloud mail server, who in turn might possibly turn around and hand certain mail (for domain users unknown to it) back to the on-premise server (this time on port 25). Since the MX will point to the cloud server, the on-premise postfix will be contacted on port 25 only by that single cloud server, for local delivery mail. Adding relayhost=cloudmail-smtp-gateway to main.cf takes care of getting external domain mail off to the cloud server. My difficulty lies with mail submission (MSA) via port 587. How to get all that handed to the gateway? I thought I could accomplish this with a simple change in master.cf by adding an option to clear out 'mydestination’: smtp … submission ... … -o mydestination= This was insufficient, as the separate trivial-rewrite daemon also needs that to know that mydestination is now empty. Next attempt: smtp … submission … … -o mydestionation= -o rewrite_service_name=submission_rewrite submission_rewrite unix - - - - - trivial-rewrite -o mydestination= This didn't work (more on that shortly). As an alternative to the above, I also tried just pointing local_transport back to the smtp transport: smtp … submission … -o local_transport=smtp:cloudmail-smtp-gateway -o rewrite_service_name=submission_rewrite submission_rewrite unix - - - - - trivial-rewrite -o local_transport=smtp:cloudmail-smtp-gateway With either of the above-style attempts, looking at "-vv" output, I am able to obtain: postfix/smtpd[PID]: resolve_clnt: `' -> `recipient@mydomain' -> transp=`smtp' host=`cloudmail-smtp-gateway:25' rcpt=`recipient@mydomain' flags= class=default This seems to indicate the message will get queued up to eventually go out via SMTP to the cloud mail gateway, exactly what I want! Yet, later in the log, I am saddened to see postfix/local[PID]: MSGID: to=, relay=local, delay=0.42, delays=0.38/0.01/0/0.03, dsn=2.0.0, status=sent (delivered to command: procmail -a "$EXTENSION") What went wrong? I don't understand postfix well enough to pinpoint what the issue might be. Somehow the transport switched from smtp back to local. I also don't know whether my general approach (of either clearing out mydestination, or replacing local_transport, during mail submission conversations) is the best strategy for getting all submitted mail on port 587 (but not mail received on port 25) handed off to the smarthost gateway? Perhaps there is an easier way to accomplish this? Thank you, Alex
Re: "SSL_Shutdown:shutdown while in init" while sending and receiving
On 14/05/20 23:15 -0400, Viktor Dukhovni wrote: That was enough of a clue for me. Please build and test the latest commit from the tls-debug branch in my git repo, you should find it works regardless of how you access Postgres... Yes, after a full day of observation today, the issue appears to have been resolved. Thank you for your time and effort. Alexander
Re: "SSL_Shutdown:shutdown while in init" while sending and receiving
On 14/05/20 01:40 -0400, Viktor Dukhovni wrote: I'f you're comfortable with gdb, and willing to build both Postfix and OpenSSL from source with debugging symbols, then you could add a "-D" flag to the "smtpd" entry in the /opt/postfix/etc/master.cf file, and attach to a "screen" running a debugger on smtpd, setting a breakpoint in SSL_shutdown, and continue. Then report a stack trace... The plot thickens. In a nutshell, the problem is "solved" by changing the virtual(8) hosts to use UNIX domain sockets (rather than e.g. 127.0.0.1). In both cases, the connection settings are for a local PostgreSQL database. While debugging in gdb, I noticed that when it would break on SSL_shutdown, the backtrace showed a bunch of pgsql stuff. Twice in a row, always. Once I continued past both SSL_shutdown breaks, it wouldn't break again on that function (and smtpd would log the "usual" 'TLS library problem' about SSL_shutdown:shutdown while in init). I thought this strange, and so I changed my approach to break on the filename/lineno combo (in my case, ssl/ssl_lib.c:2086). Same thing. So I set about quickly removing the perceived strangeness by changing the virtual(8) hosts values to use local sockets. Once I made this change, I went back to debugging the SSL_shutdown context, but the problem was gone. It's only been an hour, but as there has been no disruption to mail delivery due to the 'SSL_shutdown:shutdown while in init' issue as several emails have come and gone, I wanted to report these findings because they're quite strange. This has 'fixed' the issue for me for both sending and receiving. So, this turn of events seems to indict some facet of the postgres apparatus. I did get a backtrace of SSL_shutdown as invoked by the postgres component, but I hadn't yet put debug symbols on the table for that piece of it, so there are some unresolved symbols. Maybe it's useful. It's attached. At this point, I'd like to get postfix back to TCP connections to pgsql, so I'm going to try juggling versions of buster's postfix-pgsql to see if the issue lay there. On 14/05/20 08:06 -0400, Scott Kitterman wrote: Debian automatically builds debug symbol packages for ~all packages. They are located in a separate package repository. For instructions on how to enable it and install them, see: This was helpful and saved me a lot of time. Thanks. Alexander Breakpoint 1, SSL_shutdown (s=0x55aa36c6b630) at ../ssl/ssl_lib.c:2060 2060../ssl/ssl_lib.c: No such file or directory. #0 SSL_shutdown (s=0x55aa36c6b630) at ../ssl/ssl_lib.c:2060 #1 0x7f3bc7b9c33d in ?? () from /usr/lib/x86_64-linux-gnu/libpq.so.5 #2 0x7f3bc7b9c4a0 in ?? () from /usr/lib/x86_64-linux-gnu/libpq.so.5 #3 0x7f3bc7b84410 in PQconnectPoll () from /usr/lib/x86_64-linux-gnu/libpq.so.5 #4 0x7f3bc7b851cf in ?? () from /usr/lib/x86_64-linux-gnu/libpq.so.5 #5 0x7f3bc7b882e5 in PQsetdbLogin () from /usr/lib/x86_64-linux-gnu/libpq.so.5 #6 0x7f3bca539d35 in ?? () from /usr/lib/postfix/postfix-pgsql.so #7 0x7f3bca56e934 in dict_utf8_lookup (dict=0x55aa36c2a480, key=0x55aa36c69d20 "") at dict_utf8.c:160 #8 0x7f3bca5a48c5 in maps_find (maps=maps@entry=0x55aa36c07510, name=0x55aa36c69d20 "", flags=flags@entry=0) at maps.c:195 #9 0x7f3bca59f853 in find_addr (path=path@entry=0x55aa36c07510, address=address@entry=0x55aa36c69e60 "", flags=flags@entry=0, with_domain=with_domain@entry=1, query_form=query_form@entry=3, ext_addr_buf=ext_addr_buf@entry=0x55aa36c306e0) at mail_addr_find.c:251 #10 0x7f3bca59fc2c in mail_addr_find_opt (path=path@entry=0x55aa36c07510, address=0x55aa36c69ca0 "", extp=extp@entry=0x0, in_form=in_form@entry=1, query_form=query_form@entry=3, out_form=out_form@entry=2, strategy=23) at mail_addr_find.c:373 #11 0x55aa35f32241 in check_mail_addr_find (state=state@entry=0x7ffc8305e390, reply_name=reply_name@entry=0x55aa36c69140 "", maps=0x55aa36c07510, key=, ext=0x0) at smtpd_check.c:1185 #12 0x55aa35f32375 in check_rcpt_maps (state=state@entry=0x7ffc8305e390, sender=, recipient=recipient@entry=0x55aa36c69140 "", reply_class=, reply_class@entry=0x55aa35f498be "Sender address") at smtpd_check.c:5158 #13 0x55aa35f38bd8 in check_sender_rcpt_maps (sender=0x55aa36c69140 "", state=0x7ffc8305e390) at smtpd_check.c:5119 #14 check_sender_rcpt_maps (sender=0x55aa36c69140 "", state=0x7ffc8305e390) at smtpd_check.c:5105 #15 smtpd_check_mail (state=state@entry=0x7ffc8305e390, sender=0x55aa36c69140 "") at smtpd_check.c:4903 #16 0x55aa35f390ab in smtpd_check_rcpt (state=0x7ffc8305e390, recipient=0x55aa36c5adc0 "") at smtpd_check.c:5017 #17 0x55aa35f29e38 in rcpt_cmd (state=0x7ffc8305e390, argc=3, argv=0x55aa36c639f0) at s
Re: "SSL_Shutdown:shutdown while in init" while sending and receiving
On 13/05/20 21:58 -0400, Viktor Dukhovni wrote: Please rebuild, and post another similar set of logs. Thanks. Attached. Alexander May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: connect from [] May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: hsfunc=0x7f310ef3a780, rfunc=(nil), wfunc=(nil), SSL_get_error(-1) = 2 May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: waiting for readable socket May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: hsfunc=0x7f310ef3a780, rfunc=(nil), wfunc=(nil), SSL_get_error(-1) = 2 May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: waiting for readable socket May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: hsfunc=0x7f310ef3a780, rfunc=(nil), wfunc=(nil), SSL_get_error(1) = 0 May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: TLS success May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: Anonymous TLS connection established from []: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: hsfunc=(nil), rfunc=0x7f310ef36dd0, wfunc=(nil), SSL_get_error(-1) = 2 May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: waiting for readable socket May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: hsfunc=(nil), rfunc=0x7f310ef36dd0, wfunc=(nil), SSL_get_error(25) = 0 May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: TLS success May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: hsfunc=(nil), rfunc=(nil), wfunc=0x7f310ef37090, SSL_get_error(184) = 0 May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: TLS success May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: hsfunc=(nil), rfunc=0x7f310ef36dd0, wfunc=(nil), SSL_get_error(-1) = 2 May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: waiting for readable socket May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: hsfunc=(nil), rfunc=0x7f310ef36dd0, wfunc=(nil), SSL_get_error(12) = 0 May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: TLS success May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: hsfunc=(nil), rfunc=(nil), wfunc=0x7f310ef37090, SSL_get_error(18) = 0 May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: TLS success May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: hsfunc=(nil), rfunc=0x7f310ef36dd0, wfunc=(nil), SSL_get_error(-1) = 2 May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: waiting for readable socket May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: hsfunc=(nil), rfunc=0x7f310ef36dd0, wfunc=(nil), SSL_get_error(42) = 0 May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: TLS success May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: hsfunc=(nil), rfunc=(nil), wfunc=0x7f310ef37090, SSL_get_error(18) = 0 May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: TLS success May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: hsfunc=(nil), rfunc=0x7f310ef36dd0, wfunc=(nil), SSL_get_error(-1) = 2 May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: waiting for readable socket May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: hsfunc=(nil), rfunc=0x7f310ef36dd0, wfunc=(nil), SSL_get_error(22) = 0 May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: TLS success May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: hsfunc=(nil), rfunc=(nil), wfunc=0x7f310ef37090, SSL_get_error(37) = 0 May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: TLS success May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: hsfunc=(nil), rfunc=0x7f310ef36dd0, wfunc=(nil), SSL_get_error(-1) = 2 May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: waiting for readable socket May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: hsfunc=(nil), rfunc=0x7f310ef36dd0, wfunc=(nil), SSL_get_error(42) = 0 May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: TLS success May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: hsfunc=(nil), rfunc=(nil), wfunc=0x7f310ef37090, SSL_get_error(14) = 0 May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: TLS success May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: hsfunc=(nil), rfunc=0x7f310ef36dd0, wfunc=(nil), SSL_get_error(-1) = 2 May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: waiting for readable socket May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: hsfunc=(nil), rfunc=0x7f310ef36dd0, wfunc=(nil), SSL_get_error(36) = 0 May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: TLS success May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: AEF2F102C03E: client=[], sasl_method=LOGIN, sasl_username= May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: hsfunc=(nil), rfunc=(nil), wfunc=0x7f310ef37090, SSL_get_error(14) = 0 May 13 21:56:38 vasaconsulting postfix/smtpd[25599]: tls_bio: TLS success May 13 21:56
Re: "SSL_Shutdown:shutdown while in init" while sending and receiving
On 13/05/20 20:40 -0400, Viktor Dukhovni wrote: Your OpenSSL library looks busted. Do you have more than one set of OpenSSL libraries installed on your system? What ldd report for the "smtpd" executable? Is this the stock OpenSSL for your system, or your own build? There's just one OpenSSL library installed on the system, the stock version supplied by the OS's package manager. $ ldd | grep ssl libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x7f13e45fe000) $ strings /usr/lib/x86_64-linux-gnu/libssl.so.1.1 | grep 'OpenSSL' OpenSSL 1.1.1d 10 Sep 2019 What OS are you running? Debian GNU/Linux 10 (buster aka stable). Yesterday, I bumped libssl1.1 to the version available in the testing distribution, which is 1.1.1g, and noticed no change in the faulty behavior. Now I'm back to stable's 1.1.1d. Alexander
Re: "SSL_Shutdown:shutdown while in init" while sending and receiving
On 13/05/20 16:20 -0400, Viktor Dukhovni wrote: Try the below. Note, if build as below, it will not replace your system The output is attached. Alexander May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: connect from [] May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(-1) = 2 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: waiting for readable socket May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(-1) = 2 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: waiting for readable socket May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(1) = 0 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: Anonymous TLS connection established from []: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(-1) = 2 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: waiting for readable socket May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(25) = 0 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(184) = 0 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(-1) = 2 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: waiting for readable socket May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(12) = 0 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(18) = 0 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(-1) = 2 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: waiting for readable socket May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(42) = 0 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(18) = 0 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(-1) = 2 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: waiting for readable socket May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(22) = 0 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(37) = 0 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(-1) = 2 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: waiting for readable socket May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(42) = 0 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(14) = 0 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(-1) = 2 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: waiting for readable socket May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(36) = 0 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: C6917102C03E: client=[], sasl_method=LOGIN, sasl_username= May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(14) = 0 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS success May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: SSL_get_error(-1) = 1 May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: tls_bio: TLS layer error May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: warning: TLS library problem: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init:../ssl/ssl_lib.c:2086: May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: lost connection after RCPT from [] May 13 16:31:24 vasaconsulting postfix/smtpd[14216]: disconnect from [] ehlo=2 starttls=1 auth=1 mail=1 rcpt=1 commands=6
Re: "SSL_Shutdown:shutdown while in init" while sending and receiving
On 13/05/20 00:34 -0400, Viktor Dukhovni wrote: an SSL_ERROR_WANT_READ. You need to try an updated OpenSSL. Thanks for your insights. I'm trying new things to try to improve my understanding of the issue. I juggled around some versions. Bumped to libssl 1.1.1g, restarted postfix, problem persisted. I also went to postfix 3.5.1 (out of curiosity, after downgrading back to libssl 1.1.1d) to no avail. I'm not experiencing any other issues (that I know of) on the machine in which TLS is used heavily by other programs with greater activity than postfix. This problem distinctly began immediately after the upgrade (postfix 3.1.14 -> 3.4.10, libssl 1.1.0l -> 1.1.1d). This is not to say that the issue is definitely with postfix, just to give more information. The pattern in which an email fails due to this issue, and then succeeds upon immediately being resent is most perplexing. This is repeatable and suggests that there's some state persisting somewhere. Further, I just tried sending an email from one address via a web-based client (it failed) and immediately sending from my normal MUA, to try to isolate where that state persistence might be. It failed on both, *however*, I realized that I had forgotten to change my MUA's port back to 587 (from 588). I changed it to 587, and repeated this test, and to my surprise, the web-based client failed but the MUA succeeded. It seems like one fix, which is beyond ugly, could be to set up an email to be sent every 5 seconds through the mail server to keep the "TLS warning" state warm, allowing real emails to get through via TLS on their first attempt. As not every mail server immediately retries not over TLS upon a TLS failure, this issue is impacting delivery to a non-insignificant extent. Alexander
Re: "SSL_Shutdown:shutdown while in init" while sending and receiving
On 13/05/20 13:56 -0400, Viktor Dukhovni wrote: If you're willing to rebuild Postfix from source, then I can provide a patch that would log more details. Yes, absolutely willing. Thank you. Alexander
Re: "SSL_Shutdown:shutdown while in init" while sending and receiving
On 12/05/20 23:27 -0400, Viktor Dukhovni wrote: Once again out of the blue, a lost connection. The SMTP server is trying to read the next command after sending "RCPT TO" and encounters an EOF condition, for no apparent reason. At this point, I'd guess your SSL library is broken... I was able to squeeze a bit more information out using smtpd_tls_loglevel=4. May 12 20:47:14 vasaconsulting postfix/smtpd[15943]: > []: 250 2.1.5 Ok May 12 20:47:14 vasaconsulting postfix/smtpd[15943]: watchdog_pat: 0x55e2224ca3f0 May 12 20:47:14 vasaconsulting postfix/smtpd[15943]: vstream_fflush_some: fd 17 flush 14 May 12 20:47:14 vasaconsulting postfix/smtpd[15943]: Write 14 chars: 250 2.1.5 Ok?? May 12 20:47:14 vasaconsulting postfix/smtpd[15943]: write to 55E222534FF0 [55E222542173] (36 bytes => 36 (0x24)) May 12 20:47:14 vasaconsulting postfix/smtpd[15943]: 17 03 03 00 1f df 3e 1c|66 4c e9 c5 07 39 56 6a ..>. fL...9Vj May 12 20:47:14 vasaconsulting postfix/smtpd[15943]: 0010 ed 71 92 5b ee e6 8b e5|bd a6 9e 8f 33 68 38 74 .q.[ 3h8t May 12 20:47:14 vasaconsulting postfix/smtpd[15943]: 0020 86 60 a1 32 .`.2 May 12 20:47:14 vasaconsulting postfix/smtpd[15943]: read from 55E222534FF0 [55E22253E023] (5 bytes => -1 (0x)) May 12 20:47:14 vasaconsulting postfix/smtpd[15943]: warning: TLS library problem: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init:../ssl/ssl_lib.c:2086: May 12 20:47:14 vasaconsulting postfix/smtpd[15943]: smtp_get: EOF
Re: "SSL_Shutdown:shutdown while in init" while sending and receiving
On 12/05/20 21:07 -0400, Viktor Dukhovni wrote: At this point, clone your submission service onto port 588, and configure that copy with "smtpd -vvv" + all the other options. Then use your client to connect to port 588, and there should now be voluminous logging from the Postfix I/O layer (events and vstreams). The question is now whether Postfix is seeing EOF from OpenSSL and then reciprocating by closing the stream, or somehow deciding to close the stream (for no obvious reason). Thanks. I've attached the log, pruned to the important section. I wish I could offer an interpretation, but I'm ignorant to the arcana that's on full display in this log. Alexander May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: reply: SMFIR_CONTINUE data 0 bytes May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: before input_transp_cleanup: cleanup flags = enable_header_body_filter enable_automatic_bcc enable_address_mapping enable_milters May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: after input_transp_cleanup: cleanup flags = enable_header_body_filter enable_automatic_bcc enable_address_mapping enable_milters May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: name_mask: sendmail May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: name_mask: verify May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: connect to subsystem public/cleanup May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: vstream_buf_get_ready: fd 24 got 23 May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: public/cleanup socket: wanted attribute: queue_id May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: input attribute name: queue_id May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: input attribute value: 2F82C102C059 May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: public/cleanup socket: wanted attribute: (list terminator) May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: input attribute name: (end) May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: send attr flags = 242 May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: rec_put: type m len 1 data 0 May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: send 0 milters May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: rec_put: type T len 16 data 1589335446 May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: rec_put: type A len 22 data log_ident= May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: rec_put: type A len 22 data rewrite_co May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: rec_put: type A len 17 data sasl_metho May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: rec_put: type A len 42 data sasl_usern May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: rec_put: type S len 28 data @ May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: rec_put: type A len 51 data log_client May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: rec_put: type A len 32 data log_client May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: rec_put: type A len 21 data log_client May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: rec_put: type A len 69 data log_messag May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: rec_put: type A len 32 data log_helo_n May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: rec_put: type A len 23 data log_protoc May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: rec_put: type A len 47 data client_nam May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: rec_put: type A len 55 data reverse_cl May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: rec_put: type A len 28 data client_add May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: rec_put: type A len 17 data client_por May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: rec_put: type A len 29 data server_add May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: rec_put: type A len 15 data server_por May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: rec_put: type A len 28 data helo_name= May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: rec_put: type A len 19 data protocol_n May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: rec_put: type A len 21 data client_add May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: 2F82C102C059: client=[], sasl_method=LOGIN, sasl_username= May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: rec_put: type A len 45 data dsn_orig_r May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: rec_put: type R len 24 data May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: vstream_fflush_some: fd 24 flush 763 May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: > []: 250 2.1.5 Ok May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: watchdog_pat: 0x5571a55eaa60 May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: vstream_fflush_some: fd 17 flush 14 May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: warning: TLS library problem: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init:../ssl/ssl_lib.c:2086: May 12 19:04:06 vasaconsulting postfix/smtpd[3301]: smtp_get: EOF ...match_hostname/addr stuff... May 12 19:04:06 vasac
Re: "SSL_Shutdown:shutdown while in init" while sending and receiving
On 12/05/20 05:40 -0400, Viktor Dukhovni wrote: Indeed the server slams the TCP socket closed after receiving the client's RCPT command. Unclear why. You might try debug_peer_list next, to see whether the server can log enough cleartext traffic to expose the SMTP traffic inside TLS. Thanks. Using debug_peer_list, I have a few more pieces of information. May 12 14:27:21 vasaconsulting postfix/smtpd[3482]: > []: 235 2.7.0 Authentication successful May 12 14:27:21 vasaconsulting postfix/smtpd[3482]: watchdog_pat: 0x55bec82e41e0 May 12 14:27:22 vasaconsulting postfix/smtpd[3482]: < []: MAIL FROM:<> ...lots of debug info e.g. send attr, etc... May 12 14:27:22 vasaconsulting postfix/smtpd[3482]: > []: 250 2.1.0 Ok May 12 14:27:22 vasaconsulting postfix/smtpd[3482]: watchdog_pat: 0x55bec82e41e0 May 12 14:27:22 vasaconsulting postfix/smtpd[3482]: < []: RCPT TO:<> ...lots of debug info e.g. config maps, etc... May 12 14:27:22 vasaconsulting postfix/smtpd[3482]: > []: 250 2.1.5 Ok May 12 14:27:22 vasaconsulting postfix/smtpd[3482]: watchdog_pat: 0x55bec82e41e0 May 12 14:27:22 vasaconsulting postfix/smtpd[3482]: warning: TLS library problem: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init:../ssl/ssl_lib.c:2086: May 12 14:27:22 vasaconsulting postfix/smtpd[3482]: smtp_get: EOF ...some match_hostname stuff, etc... May 12 14:27:22 vasaconsulting postfix/smtpd[3482]: lost connection after RCPT from [] ...abort milter stuff... May 12 14:27:22 vasaconsulting postfix/smtpd[3482]: disconnect from [] ehlo=2 starttls=1 auth=1 mail=1 rcpt=1 commands=6 The server opened a queue file, which by default happens only after the first recipient is accepted. Is there really no other logging for this process at that time? That's correct. Just those three lines (plus the warning about TLS library issue). What follows is how the conversation above ended. Different than the PCAP I attached yesterday, this is me sending an email as opposed to an email being sent to me (it's easier to use debug_peer_list with a predictable peer aka myself). There's no Encrypted Alert, and only one RST. I don't know if that's pertinent or not. [Time since reference or first frame: 0.861553000 seconds] Transmission Control Protocol, Src Port: 587, Dst Port: 37049, Seq: 7301, Ack: 748, Len: 0 Flags: 0x011 (FIN, ACK) [Time since reference or first frame: 0.907717000 seconds] Transmission Control Protocol, Src Port: 37049, Dst Port: 587, Seq: 748, Ack: 7302, Len: 28 Flags: 0x018 (PSH, ACK) Transport Layer Security TLSv1.3 Record Layer: Application Data Protocol: smtp [Time since reference or first frame: 0.907756000 seconds] Transmission Control Protocol, Src Port: 587, Dst Port: 37049, Seq: 7302, Len: 0 Flags: 0x004 (RST) Alexander
Re: "SSL_Shutdown:shutdown while in init" while sending and receiving
On 11/05/20 23:35 -0400, Viktor Dukhovni wrote: Attaching it is fine, if you're willing to disclose the IP addresses and hostnames of the two servers. Okay, I've attached two files; the PCAP and the postfix log. To clarify my earlier email, the unencrypted session scenario only arises when I receive mail. It seems that when a foreign mail server connects to mine to send me a message, it fails, then retries sometime later NOT over TLS, and that succeeds. When I send mail, it fails the first time, and then as long as I immediately resend, it succeeds (over TLS, thankfully). I've also seen at least one sender (notably, GMAIL) connect, elicit the SSL_Shutdown error, and yet their message gets queued and delivered without another try being needed. Alexander postfix-SSL_Shutdown.pcap Description: application/vnd.tcpdump.pcap May 11 19:29:04 vasaconsulting postfix/smtpd[14174]: connect from mail1.bemta23.messagelabs.com[67.219.246.1] May 11 19:29:05 vasaconsulting postfix/smtpd[14174]: Anonymous TLS connection established from mail1.bemta23.messagelabs.com[67.219.246.1]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) May 11 19:29:06 vasaconsulting postfix/smtpd[14174]: 80D73102C036: client=mail1.bemta23.messagelabs.com[67.219.246.1] May 11 19:29:06 vasaconsulting postfix/smtpd[14174]: warning: TLS library problem: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init:../ssl/ssl_lib.c:2086: May 11 19:29:06 vasaconsulting postfix/smtpd[14174]: lost connection after RCPT from mail1.bemta23.messagelabs.com[67.219.246.1] May 11 19:29:06 vasaconsulting postfix/smtpd[14174]: disconnect from mail1.bemta23.messagelabs.com[67.219.246.1] ehlo=2 starttls=1 mail=1 rcpt=1 commands=5
Re: "SSL_Shutdown:shutdown while in init" while sending and receiving
The real problem is that the connection was terminated mid-transaction. The "shutdown while in init" is I think a distraction, Postfix was cleaning up the TLS session, when it was not yet, or is no longer in a state that is valid for calling SSL_shutdown(). If you manage to collect a PCAP capture of the traffic for a failed delivery, it should be possible (especially if limited to TLS 1.2, which is a bit easier to debug from TCP captures) to see whether the failure is at the application or TCP layer. I think your next step is to get a PCAP of the traffic. I've captured the relevant conversation. In doing so, it became clear to me that when the message succeeds after immediately trying again, it does so because the subsequent connection does not try to use TLS. So the pattern is: attempt TLS connection, fail, attempt plaintext connection, succeed. This was alarming to realize. From the pcap, in brief: I see the connection, STARTTLS, TLSv1.2 handshake succeed, "application data" packets being exchanged using TLSv1.2. Finally, my mail server sends two TCP packets with the RST flag set. Between those two packets is an 'encrypted alert' packet from the foreign mailserver. I'm not certain on the norms of this mailing list but I can put the entire pcap somewhere if it would be helpful, it's 35 frames long. Alexander
Re: "SSL_Shutdown:shutdown while in init" while sending and receiving
times it's like this: May 11 12:28:07 vasaconsulting postfix/smtpd[29124]: lost connection after DATA (0 bytes) from english-breakfast.cloud9.net[168.100.1.7] And other times, it's like this: May 11 12:20:57 vasaconsulting postfix/smtpd[28652]: lost connection after RCPT from [] Just in case this is an OpenSSL glitch, you should at this point be using OpenSSL 1.1.1g. I can upgrade OpenSSL to 1.1.1g, but it would go outside of the stable "channel" of my distribution, so it's not a preferred approach. I recognize that this is a symptom of an underlying problem, just trying to figure out what that underlying problem might be. Thanks. Alexander
"SSL_Shutdown:shutdown while in init" while sending and receiving
Greetings, I recently upgraded postfix and OpenSSL to 3.4.10 and 1.1.1d, respectively. These versions align with Debian GNU/Linux 10 (buster). Since the upgrade I've begun receiving regular log entries that look like this: May 11 11:23:54 vasaconsulting postfix/smtpd[21870]: warning: TLS library problem: error:140E0197:SSL routines:SSL_shutdown:shutdown while in init:../ssl/ssl_lib.c:2086: These happen both when receiving and sending messages. Notably, when sending, the send will fail, but if I immediately resend, the message goes through. If instead I wait 10 or so seconds before resending, it will fail. When it occurs when receiving, the sending mailserver retries sometime later and seems to get through (though I haven't sought to verify repeated failures). I've seen this failure on both TLS v1.2 and v1.3 connections. Some messages seem to succeed as normal and expected but most fail due to this error and I haven't been able to identify a pattern. A survey of the mailing list suggests the problem as experienced by another user may have been related to tlsproxy but I have smtp_tls_connection_reuse set to no. Thanks and regards, Alexander Vasarab
Re: dnsblog_query: lookup error for DNS query x.x.x.x.zen.spamhaus.org: Host or domain name not found.
> A possible cause is that you are not using your own DNS resolver but > instead relying on a third party (such as your ISP), and their > resolver has been blocked by Spamhaus for over-usage. In which case > you need to set up your own DNS resolver (e.g. bind) and use this > instead, ensuring it does not forward DNS queries through a > third-party resolver. The first two nameserver entries in my resolv.conf contains IPv4 127.0.0.1 and IPv6 ::1 > Does the 'test' address work? See > https://www.spamhaus.org/faq/section/DNSBL%20Usage#366 > > $ dig +short 2.0.0.127.zen.spamhaus.org @DNS.server > > for relevant values of 'DNS.server' including 127.0.0.1. dig @127.0.0.1 1.0.0.127.zen.spamhaus.org +short ; <<>> DiG 9.14.8 <<>> @127.0.0.1 1.0.0.127.zen.spamhaus.org +short ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached dig @127.0.0.1 denic.de +short a 81.91.170.12 A dig to query other domains for whatever records does work, so i guess it's not a firewall issue. Beside this i tried disabling my firewall for a moment of second to doublecheck if my firewall has problem. No changes, still not reaching zen.spamhaus.org. UDP/TCP 53 is open at switch/router-level and my server too.
dnsblog_query: lookup error for DNS query x.x.x.x.zen.spamhaus.org: Host or domain name not found.
Hey folks, for inexplicable reasons i don't get any results from zen.spamhaus.org anymore: Apr 08 16:20:29 [postfix/dnsblog] warning: dnsblog_query: lookup error for DNS query x.x.x.x.zen.spamhaus.org: Host or domain name not found. Name service error for name=x.x.x.x.zen.spamhaus.org type=A: Host not found, try again I knew the free-to-use requirements from Spamhaus and i didn't think that i ever would reach this regulations. (non-commercial, less than 100.000 smtp/day, less 300.000 queries/day) As local DNS resolver i am using unbound which interacts with Spamhaus. For a fallback solution, whenever unbound isn't accessible for whatever reason, i added my provider (Hetzner) nameservers as well. nameserver ::1 nameserver 127.0.0.1 nameserver 213.133.99.99 nameserver 213.133.100.100 nameserver 213.133.98.98 nameserver 2a01:4f8:0:a111::add:9898 nameserver 2a01:4f8:0:a102::add: nameserver 2a01:4f8:0:a0a1::add:1010 Since a month i am getting no such results from Spamhaus anymore, so i stopped using them via Postfix. My setup contains approx 10 email addresses which receive approx 30-40 emails/day. Can i do something to revert this blocking from Spamhaus? Like not quering for x days the list or so? Any other solutions? Thanks for response. Kind regards. Alex
Re: Postfix log
On Fri, 09 Aug 2019, Benny Pedersen wrote:
Hi,
> > Thanks, postscript is not part of the Debian package. I'll try to put:
> > service postfix restart
>
> this is not working, postfix send logs to syslogd, so restarting postfix is
> not what to do, restart the syslogd will work
>
> please create a bug on debian so it can be resolved, its default logrotate
> problem that does not restart syslogd
The default syslogd (rsyslogd) in debian does that:
/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
{
rotate 4
weekly
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
/usr/lib/rsyslog/rsyslog-rotate
endscript
}
cat /usr/lib/rsyslog/rsyslog-rotate
#!/bin/sh
if [ -d /run/systemd/system ]; then
systemctl kill -s HUP rsyslog.service
else
invoke-rc.d rsyslog rotate > /dev/null
fi
Re: Use postfix and spamassassin packages on CentOS 6 to reject SPAM
Hello again,
On Tue, Aug 12, 2014 at 9:34 AM, Alexander Farber <
alexander.far...@gmail.com> wrote:
> On 11 Aug 2014, at 10:22, li...@rhsoft.net wrote:
>>
>>> http://serverfault.com/questions/619537/use-postfix-
>>> and-spamassassin-packages-on-centos-6-to-reject-spam-without-custo
>>>
>>
the point of my question (maybe I haven't stated it clearly enough) has
been: how to combine Postfix and Spamassassin on CentOS with minimal
efforts.
I didn't want to add custom shell scripts or users - as suggested in many
HOWTOs on the web.
I think I have the answer now:
1) Install the spamassassin package (the postfix package is installed by
default)
2) Add a user to your system with "useradd spam" (you can't omit this step
- this has been the culprit in my case - I was trying to use the user
"nobody", but it didn't have a home dir and that has broken Spamassassin
despite me passing "-x" to spamd)
3) Add "/^Subject: \[SPAM\]/ DISCARD" to the /etc/postfix/header_checks
(check the /etc/mail/spamassassin/local.cf to see the exact string to match)
4) Add the following 2 lines to the /etc/postfix/master.cf:
smtp inet n - n - - smtpd -o content_filter=spamassassin
spamassassin unix - n n - - pipe user=spam argv=/usr/bin/spamc -f -e
/usr/sbin/sendmail -oi -f ${sender} ${recipient}
Regards
Alex
Re: Use postfix and spamassassin packages on CentOS 6 to reject SPAM
On Tue, Aug 12, 2014 at 1:44 AM, Bill Cole < postfixlists-070...@billmail.scconsult.com> wrote: > On 11 Aug 2014, at 10:22, li...@rhsoft.net wrote: > >> http://serverfault.com/questions/619537/use-postfix- >> and-spamassassin-packages-on-centos-6-to-reject-spam-without-custo >> > > Also worth noting: embedding the GTUBE pattern in a message is an > excellent way to minimize visibility of a message among SpamAssassin users. > The GTUBE mail (and the other mails I try) come through, because I haven't touched header_checks yet. The problem is - why don't subjects get rewritten by Spamassassin - despite having "rewrite_header Subject [SPAM]" in /etc/mail/spamassassin/local.cf? But maybe the Postfix side is okay and I should ask at the Spamassassin mailing list - even though Mr. rhsoft.net disapproves. Regards Alex
Re: Disabling Anonymous Diffie Hellman
On 20.05.2014 16:21, Viktor Dukhovni wrote: We did discuss and change the scoring soon after the service launched, while originally being based on the scoring system from Ivan Ristic @ Qualys at ssllabs.com for https. Yes, perhaps stupid, but it seemed better than creating our own scoring system. Opportunistic TLS in SMTP is nothing like mandatory TLS in HTTPS. Yes, it uses the same protocol engine, but the threat model is completely different. The sooner people stop carrying over flawed reasoning from HTTPS to SMTP+STARTTLS the better. Please change your site to reflect the correct risk model (opportunistic TLS). You should also add support for DANE, so that DANE-capable MTAs are not mis-identified as insecure (for example DANE-EE(3) certificate usage obviates the need for the hostname to match). I second this. I have been using the site since it became public and have discussed the same with the designers ad nauseum, and there seems to be little interest in wanting to understand that TLS in context of HTTP and SMTP are two very different worlds in terms of starting problems and possible archievements. I run what I consider to be fairly well configured MXes for customers, and this site generally tends to cap my score at 68% given the support for weaker protocols. Not only is it misleading for people trying to configure their own servers, but it has drawn attention from customers which not always have the understanding of why this site hands out these scores it does. So basically, untill the site can relfect the real world, it seem to be of limited use. mvh, A -- Alexander Hoogerhuis | http://no.linkedin.com/in/alexh Boxed Solutions AS | +47 908 21 485 - al...@boxed.no "Given enough eyeballs, all bugs are shallow." -Eric S. Raymond
Re: Do not send mails to addresses with more than 3 dots in username part
I see, thanks to you both! The #danger doc not probably doesn't apply here, but still good to know.
Re: Do not send mails to addresses with more than 3 dots in username part
postconf |grep smtpd_recipient_restrictions smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination
Re: Do not send mails to addresses with more than 3 dots in username part
$ grep smtpd_recipient_restrictions /etc/postfix/main.cf # through Postfix. See the smtpd_recipient_restrictions parameter # relay mail to. See the smtpd_recipient_restrictions description in $ postconf -n alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 header_checks = pcre:/etc/postfix/header_checks html_directory = no inet_interfaces = all inet_protocols = ipv4 mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mydestination = $myhostname, localhost.$mydomain, localhost newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES sample_directory = /usr/share/doc/postfix-2.6.6/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtp_generic_maps = hash:/etc/postfix/generic unknown_local_recipient_reject_code = 550 virtual_alias_domains = videoskat.de balkan-preferans.de simplex.ru preferans.de larissa-farber.de bukvy.de virtual_alias_maps = hash:/etc/postfix/virtual On Sat, Nov 23, 2013 at 3:16 PM, tejas sarade wrote: > I would like to know current recipient restrictions. What is the output of > following command. > > grep smtpd_recipient_restrictions /etc/postfix/main.cf > > > > On Sat, Nov 23, 2013 at 4:43 PM, Alexander Farber < > alexander.far...@gmail.com> wrote: > >> Does this doc really apply to my situation? >> (I'd like to discard some of the mails sent out by my CMS) >> >> On Sat, Nov 23, 2013 at 11:42 AM, tejas sarade >> wrote: >>> >>> http://www.postfix.org/SMTPD_ACCESS_README.html >>> >> Regards >> Alex >> > >
Re: Do not send mails to addresses with more than 3 dots in username part
Does this doc really apply to my situation? (I'd like to discard some of the mails sent out by my CMS) On Sat, Nov 23, 2013 at 11:42 AM, tejas sarade wrote: > > http://www.postfix.org/SMTPD_ACCESS_README.html > Regards Alex
Re: Do not send mails to addresses with more than 3 dots in username part
Hello Peter and others, On Sat, Nov 23, 2013 at 1:38 AM, Peter wrote: > On 11/23/2013 12:38 AM, Alexander Farber wrote: > > /etc/postfix/header_checks: > > /^To: \S+\.\S+\.\S+\.\s...@gmail.com <mailto:s...@gmail.com>$/i DISCARD > > > > /etc/postfix/main.cf <http://main.cf>: > > header_checks = pcre:/etc/postfix/header_checks > > Header checks will certainly work, but it requires that postfix does > deep inspection of the message DATA in order to and before it can reject > the message. You're much better off checking the envelope recipient > with a check_recipient_access restriction. This too can use a pcre > table so you can match the recipient address against a regular > expression with three dots, then postfix won't have to do deep > inspection of the DATA packet, and can reject the mail at the RCPT TO > stage before the DATA is even transmitted to postfix, much more efficient. > thank you! So I have moved the line /^To: \S+\.\S+\.\S+\.\s...@gmail.com$/i DISCARD to the file /etc/postfix/access, but when I run # postmap /etc/postfix/access I get the warning: postmap: warning: /etc/postfix/access, line 452: record is in "key: value" format; is this an alias file? postmap seems not to like the whitespace after "To:", should I replace that space by \s+ as workaround? Or can I somehow tell postmap (I've read its manpage, but haven't find the answer), that it is a pcre database? And another question is what directive to put into main.cf to enable the check_recipient_access for OUTGOING mails? Regards Alex
Re: Do not send mails to addresses with more than 3 dots in username part
Yes, ok - it's my fault. Next time I will ask a Postfix question here, I shouldn't forget to add a disclaimer "and please no CMS or web admin advice needed" ;-)
Re: Do not send mails to addresses with more than 3 dots in username part
I've spent last 2 hours with Drupal CAPTCHA module - the default image and math captchas didn't stop any spam user at all - I could see fake users still registering - every few seconds (scary!). I have uploaded a russian font then and configured the CAPTCHA to use russian letters only (since my site is targeting Russian users) - this has stopped them for now. I'm just saying, that the whole problem isn't trivial and obvious comments (install captcha etc.) aren't really helping here, that's why I asked the specific postfix question here... Have a nice day, sorry for offtopic ramblings Alex
Re: Do not send mails to addresses with more than 3 dots in username part
Yes, Reindl, thanks again for all these _obvious_ advices, while I was just asking a specific Postfix-related one. On Fri, Nov 22, 2013 at 1:03 PM, li...@rhsoft.net wrote: > my last post in this thread because we are going off-topic > > discard messages on a MTA is the *last resort* if nothing > else happens but not the solution for a broken web-app > because it is the wrong layer >
Re: Do not send mails to addresses with more than 3 dots in username part
I admin this website for 3 years already and despite it being just a small obscure card game - there haven't been a month without a challenge, where I had to go and change something manually. This postfix workaround is pretty perfect for now, I enjoy looking at maillog right now and see the Nov 22 12:46:24 www postfix/cleanup[6977]: 7D4218048A0: discard: header To: pre.a.c.hfc...@gmail.com from local; from= Nov 22 12:46:27 www postfix/pickup[6966]: E59B88048A0: uid=48 from= Nov 22 12:46:27 www postfix/cleanup[6977]: E59B88048A0: discard: header To: fu.t.i.li.t.y.g.i@gmail.com from local; from= Nov 22 12:46:30 www postfix/pickup[6966]: 266D88048A5: uid=48 from= flying through (every 3 seconds!) and those bastard messages being discarded. If you think, that a CAPTCHA or anything else will stop all the problems and you never have to touch anything, you are so wrong :-)
Re: Do not send mails to addresses with more than 3 dots in username part
Thanks, I agree with all general advices... But for now I just want to stop the flood (and also Drupal is difficult to modify for me + I don't want to add CAPTCHA to my already overloaded reg. form, etc., etc.). So the following seems to work for me for now - /etc/postfix/header_checks: /^To: \S+\.\S+\.\S+\.\s...@gmail.com$/i DISCARD /etc/postfix/main.cf: header_checks = pcre:/etc/postfix/header_checks
Re: Do not send mails to addresses with more than 3 dots in username part
Hello, I know regexes well - but can't figure out, where to applly them in Postfix, since smtp_header_checks with DISCARD action seems not to be supported with OUTGOING mail? On Fri, Nov 22, 2013 at 11:22 AM, Robert Schetterer wrote: > > > Am 22.11.2013 10:48, schrieb Alexander Farber: > > > I'd like my postfix to drop OUTGOING mail silently if addressed to > > us.er.n.a...@gmail.com <mailto:us.er.n.a...@gmail.com> > > drop silent isnt a good idea, however you need some regex or pcre sender > restriction in combination only for out mail to do that. >
Re: Do not send mails to addresses with more than 3 dots in username part
I think I'd like to use smtp_header_checks with DISCARD action - but http://postfix.org/header_checks.5.html says such a combination is not supported?
Re: Do not send mails to addresses with more than 3 dots in username part
On Fri, Nov 22, 2013 at 10:45 AM, li...@rhsoft.net wrote: > > problems needs to be solved on the root cause not worked around somewhere > else > No, at the moment I am looking for the Postfix workaround. I'd like my postfix to drop OUTGOING mail silently if addressed to us.er.n.a...@gmail.com Regards Alex
Re: Do not send mails to addresses with more than 3 dots in username part
Should I use smtp_header_checks here? I have also asked the question at http://serverfault.com/questions/556723/silently-drop-outgoing-mails-to-us-er-n-a-megmail-com-more-than-3-dots-in-user (And I apologize for my mail being not in plain text - I use Gmail and they have changed their interface again) Regards Alex
Do not send mails to addresses with more than 3 dots in username part
Hello, I run a Drupal 7 website on a CentOS 6.4 server with postfix-2.6.6-2.2.el6_1.x86_64. In the last few months the amount of fake users trying to register at my website has increased dramatically - I get 2 or 3 of such registrations per minute. Mostly they have fake mail adresses with many dots and at gmail.com: c.ar.eer.t...@gmail.com all.ego.ry.nl@gmail.com b.is.on.bk@gmail.com notab.ly.ib@gmail.com p.os.t.h.um.o.u.szd@gmail.com At the end those users can't register, because a mail confirmation is required. But my mailbox is filled with mail bounces and in the /var/log/maillog I see my site contacting Gmail servers again and again: Nov 17 07:05:07 www postfix/smtp[14348]: 182A6803FD2: to=< p.os.t.h.um.o.u.szd@gmail.com>, relay=alt1.gmail-smtp-in.l.google.com[74.125.143.27]:25, conn_use=6, delay=21589, delays=21586/2.6/0.11/0.5, dsn=4.2.1, status=deferred (host alt1.gmail-smtp-in.l.google.com[74.125.143.27] said: 450-4.2.1 The user you are trying to contact is receiving mail too quickly. 450-4.2.1 Please resend your message at a later time. If the user is able to 450-4.2.1 receive mail at that time, your message will be delivered. For more 450-4.2.1 information, please visit 450 4.2.1 http://support.google.com/mail/bin/answer.py?answer=6592pw9si3558657lbb.147 - gsmtp (in reply to RCPT TO command)) The latter makes me very worried (that my website will be put on a black list). I haven't found a good Drupal solution for my problem yet. My question is if there is a way (as a temporary workaround until I find a Drupal side solution) to stop my postfix information from sending mail to any users at gmail.com domain - when they have more than 3 dots in the username part of the mail address? I'm okay if I miss few false positives, since my website is just a small card game site and also I have yet to see legit users with three or more dots. Please point me to a right direction as I am a Postfix newbie and don't know where to start looking. My "postconf -n" output is below (I use virtual_alias_domains to accept mail for several Drupal sites hosted as Apache vhosts at my dedicated server). Thank you Alex postconf -n: alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases command_directory = /usr/sbin config_directory = /etc/postfix daemon_directory = /usr/libexec/postfix data_directory = /var/lib/postfix debug_peer_level = 2 html_directory = no inet_interfaces = all inet_protocols = ipv4 mail_owner = postfix mailq_path = /usr/bin/mailq.postfix manpage_directory = /usr/share/man mydestination = $myhostname, localhost.$mydomain, localhost newaliases_path = /usr/bin/newaliases.postfix queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES sample_directory = /usr/share/doc/postfix-2.6.6/samples sendmail_path = /usr/sbin/sendmail.postfix setgid_group = postdrop smtp_generic_maps = hash:/etc/postfix/generic unknown_local_recipient_reject_code = 550 virtual_alias_domains = videoskat.de balkan-preferans.de simplex.ru preferans.de larissa-farber.de bukvy.de virtual_alias_maps = hash:/etc/postfix/virtual
Re: Google rejecting IPv6 mails
On 10.10.2013, at 14:55, Andreas Herrmann wrote: > <***@gmail.com>: host gmail-smtp-in.l.google.com[2a00:1450:4001:c02::1a] >said: 550-5.7.1 [2a01:4f8:d16:4114:feed:1bad:beef:dead 1] Our > system >has 550-5.7.1 detected an unusual rate of unsolicited mail > originating from >your IP 550-5.7.1 address [...] > > Just an idea: > Google is blocking the complete 2a01:4f8::/32AS24940 > (HETZNER-RZ-NBG-IPV6-BLK1) and doesn't care abut seperate subnets like > Luigi's 2a01:4f8:d16:2409::/64 or my 2a01:4f8:d16:4114::/64 :-( I am not so sure if this is the reason, I have (and had) no problems sending to google and I am in the same network range (Hetzner): Oct 10 19:12:46 tldr postfix/smtp[1791]: 5E0AAF0246: to=, relay=aspmx.l.google.com [2a00:1450:4001:c02::1b]:25, delay=2.3, delays=0.18/0.01/0.38/1.8, dsn=2.0.0, status=sent (250 2.0.0 OK 1381425166 x49si37444641een.324 - gsmtp) -Alex
Re: Using postfix in CentOS 6 to relay mails to first.l...@gmail.com
Hello Wietse - On Wed, Jan 16, 2013 at 2:43 PM, Wietse Venema wrote: > Alexander Farber: > HOWEVER, there is one problem that you need to be aware of. If your > machine forwards SPAM to gmail, then gmail will decide that your > server is a spammer. Gmail may then file "good" mail from your > machine to the spam folder. That happened when my wife forwarded > all her mail from work to gmail. > >> # postmap /etc/postfix/virtual >> # service reload postfix >> >> I've found that in >> http://www.postfix.org/VIRTUAL_README.html#virtual_alias > > You did a good job of reading. thank you for your software and the advice! I'll read up more on spam filtering and I've changed the /etc/postfix/virtual to hold certain addresses instead of wildcards wxxxbmas...@balkan-preferans.de first.l...@gmail.com wxxxbmas...@videoskat.de first.l...@gmail.com Also I've registered the above addresses as my "Send mail as:" in Gmail-settings - maybe it will like them better then ;-) Regards Alex
Re: Using postfix in CentOS 6 to relay mails to first.l...@gmail.com
Hello - On Tue, Jan 15, 2013 at 3:05 PM, Wietse Venema wrote: > http://www.postfix.org/BASIC_CONFIGURATION_README.html with CentOS 6 I've ended up adding inet_interfaces = all virtual_alias_domains = videoskat.de balkan-preferans.de to /etc/postfix/main.cf and @balkan-preferans.de first.l...@gmail.com @videoskat.de first.l...@gmail.com to /etc/postfix/virtual and then # postmap /etc/postfix/virtual # service reload postfix I've found that in http://www.postfix.org/VIRTUAL_README.html#virtual_alias Thanks Alex
Re: Using postfix in CentOS 6 to relay mails to first.l...@gmail.com
Hello - On Tue, Jan 15, 2013 at 2:36 PM, Reindl Harald wrote: > so the domain "videoskat.de" is not listed in your postfix config > > mydestination > local_recipient_maps > > did you read any documentation or are you starting blindly > from the centos-defaults and try to figure all knowledge > out auf mailing-lists? this will not work in most cases! Actually yes I do start blindly from centos 6 default config. Because docs are huge and I don't even know for what *keywords* to look there. I.e. what is the name for my setup (trying to forward mails addressed to other domains) - is it "virtual smth."? And also since Gmail is involved I believe it is always a good idea to ask at the mailing lists first - because they do special things sometimes. Regards Alex
Re: Using postfix in CentOS 6 to relay mails to first.l...@gmail.com
Thanks for replying - On Tue, Jan 15, 2013 at 1:55 PM, Wietse Venema wrote: > Alexander Farber: >> And have opened port 25 in the firewall: >> >> But now when I send a mail to s...@videoskat.de >> there is nothing to see in postfix logs: > > Nothing happens unless a connection is made. Does tcpdump > show any connections coming to your system at TCP port 25? sorry for the stupid question, but how to use tcpdump to check for incoming connections? I've come up only with these commands sofar: # netstat -an |grep -w 25 tcp0 0 127.0.0.1:250.0.0.0:* LISTEN # iptables -L|grep -w smtp ACCEPT tcp -- anywhere anywherestate NEW tcp multiport dports smtp,ssh Thanks Alex
Using postfix in CentOS 6 to relay mails to first.l...@gmail.com
Hello, I'm using: # cat /etc/*release CentOS release 6.3 (Final) # rpm -qa | grep post postfix-2.6.6-2.2.el6_1.x86_64 on 2 servers: preferans.de and (yes, funny name) static.103.78.9.176.clients.your-server.de I own several domains and would like all incoming mails addressing those domains to be forwarded to my Gmail address. So I have setup the MX-records for my domains: # host videoskat.de videoskat.de has address 176.9.40.169 videoskat.de mail is handled by 100 static.103.78.9.176.clients.your-server.de. videoskat.de mail is handled by 10 preferans.de. # host balkan-preferans.de balkan-preferans.de has address 176.9.40.169 balkan-preferans.de mail is handled by 100 static.103.78.9.176.clients.your-server.de. balkan-preferans.de mail is handled by 10 preferans.de. And at the both servers I have added: # head /etc/postfix/virtual @balkan-preferans.de first.l...@gmail.com @videoskat.de first.l...@gmail.com # postmap /etc/postfix/virtual # postmap -q "@videoskat.de" /etc/postfix/virtual first.l...@gmail.com And have opened port 25 in the firewall: # grep -w 25 /etc/sysconfig/iptables -A INPUT -p tcp -m state --state NEW -m tcp -m multiport --dports 25,22 -j ACCEPT But now when I send a mail to s...@videoskat.de there is nothing to see in postfix logs: # sudo tail /var/log/maillog Jan 15 10:50:42 postfix/postfix-script[1401]: starting the Postfix mail system Jan 15 10:50:42 postfix/master[1402]: daemon started -- version 2.6.6, configuration /etc/postfix So I'm probably missing something? BTW the daily logwatch mails arrive from both servers just fine at my Gmail-mailbox first.l...@gmail.com Thank you for any hints Alex
Re: LDAP schema for Postfix ? (Out of Office Notice)
Sehr geehrte Damen und Herren, Ich bin von 2012-02-27 bis einschließlich 2012-03-16 nicht im Büro. Während dieser Zeit habe ich keinen Zugriff auf meinen Email Account und kann Ihre Nachricht daher erst ab 2012-02-19 lesen. In dringenden Fällen wenden Sie sich bitte an unsere Zentrale unter +43 (1) 699 33 99-0 oder via Email an . mit freundlichen Grüßen, Alexander J. Trentini ITdesign Software Projects & Consulting GmbH Anton Freunschlag-Gasse 49, A-1230 Wien Tel.: +43 (1) 699 33 99-58, Fax: DW -33 Mobil +43 (664) 811 49 82 mailto:alexander.trent...@itdesign.at http://www.itdesign.at/ Firmenbuchnummer: FN 192969d Firmenbuchgericht: HG Wien >>> Jerry 03/02/12 12:56 >>> qS4O1/zhKokFUb1Q8Rj4Eb69WVflXEehJ35DgChVTE5n50eaGyMLOfH8AOodoSM4PVYAQgQdBulOa+knklYks3vAuQ+uX492lTl+A+e8qBV2AKoXalVKFfyuUp0pUp1ARaUHh82lv9MN+Ig7CZtgE6FNYvjlywT2VP2dMgOG46gTIWcqdfvuwyXNz0oMJNd/N5lh1YNiJt19ADTUo3VuFSNeQwVqRSrGjSCp53fk2g+Mvfk/gfoPxHeUS8MH9vRAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQnol7G0DbdBZTUELml5NSE9iG9LlCWtg7uww7+wAVV8pX1rtrGUjAqX9ZHfhDkot3IJj+jz Sender: owner-postfix-us...@postfix.org Precedence: bulk List-Post: <mailto:postfix-users@postfix.org> List-Help: <http://www.postfix.org/lists.html> List-Unsubscribe: <mailto:majord...@postfix.org> List-Subscribe: <mailto:majord...@postfix.org> X-OriginalId: qfq22BusEL023676 X-NEXT-HOP: 10.1.1.24 On Fri, 02 Mar 2012 10:38:52 +0100 Frank Bonnet articulated: > Does a Postfix specific (Open)LDAP schema exists ? > or a "mail server specific" ? There is, at least to my knowledge, no custom "Postfix schema" available. If one was actually available, I might consider using LDAP as opposed to MySQL. Then again, maybe not. MySQL is, at least for me, a lot easier to setup and populate. -- Jerry * postfix-u...@seibercom.net _ TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html
duplicate mail elimination
Hi! I am trying to understand how duplicate mail elimination works in postfix. According to previous postings, mails that are duplicated by resolving multiple recipient aliases that refer to the same final address cannot be suppressed because local(8) doesn't currently handle that case. http://thread.gmane.org/gmane.mail.postfix.user/222900/focus=222906 However, some kind of deduplication might actually be done, because the local(8) man-page tells: 8< While expanding aliases, ~/.forward files, and so on, the program attempts to avoid duplicate deliveries. The dupli- cate_filter_limit configuration parameter limits the num- ber of remembered recipients. [...] duplicate_filter_limit (1000) The maximal number of addresses remembered by the address duplicate filter for aliases(5) or vir- tual(5) alias expansion, or for showq(8) queue dis- plays. 8< Unfortunately my problem is quite similar to the issue cited above (brought up in the beginning of this month), so I am not actually expecting a solution. I'm just trying to understand which deduplication cases are handled by postfix and which are not... In my case, I have two aliases: testgrp1: user testgrp2: user If I send a mail to both groups, it will be delivered twice. In contrast, if I add a group testgrp12 that contains testgrp1 and testgrp2 and send the mail to this address, deduplication works. I guess thats because in the first case, even though a single local(8) process handles both addresses, multiple recipients are apparently handled separately. Is there any workaround? (I could use procmail as mailbox delivery agent and filter by duplicate message ids but this won't work for recipients with forwards...) Thanks in advance, --leo -- e-mail ::: Leo.Bergolth (at) wu.ac.at fax ::: +43-1-31336-906050 location ::: IT-Services | Vienna University of Economics | Austria
Re: Postfix STARTTLS bug on SLES11 SP1 still unfixed ? (solved !)
Hi, just for info, it has been fixed on saturday. postconf | grep mail_ver mail_version = 2.5.6 rpm -qa | grep postfix postfix-2.5.6-5.6.1 Nessus scan is fine. Best regards, Alexander
Re: Postfix STARTTLS bug on SLES11 SP1 still unfixed ?
Hi, just learned about http://support.novell.com/security/cve/ and especially http://support.novell.com/security/cve/CVE-2011-0411.html. Just for future requests... Answer from Novell "The updates for this issue are in QA and will be released to the update channels in the next week." Fine. Have a nice weekend. Alexander
Re: Postfix STARTTLS bug on SLES11 SP1 still unfixed ?
> The right forum is a SuSE support forum. Ok, I will go there. Your server needs to be patched if either: - remote sites verify your certificate when sending email over TLS. This is the case on my server. Thanks for the answer anyway :-) Best regards, Alexander
Postfix STARTTLS bug on SLES11 SP1 still unfixed ?
Hello, I am running SLES 11 SP1 (SuSE Linux Enterprise Server). After all patches are applied from standard update Novell sources it seems to me that STARTTLS bug is still unfixed. postconf | grep mail_version mail_version = 2.5.6 rpm -qa | grep postfix postfix-devel-2.5.6-5.4.21 postfix-doc-2.5.6-5.4.21 postfix-2.5.6-5.4.21 more /etc/SuSE-release SUSE Linux Enterprise Server 11 (x86_64) VERSION = 11 PATCHLEVEL = 1 zypper lu Loading repository data... Reading installed packages... No updates found. A security scan with Nessus said: Synopsis: The remote mail service allows plaintext command injection while negotiating an encrypted communications channel ... Plugin output: Nessus sent the following two commands in a single packet : STARTTLS\r\nRSET\r\n And the server sent the following two responses : 220 2.0.0 Ready to start TLS 250 2.0.0 Ok Am I doing somthing wrong in general or with my updates (it seems to work as far as I know) ? Should I take antoher version like this one: http://download.opensuse.org/repositories/server:/mail/SLE_11/x86_64/ ? I verified this issue on another of my servers with same rseults... Thank you for an answer in advance and best regards, Alexander
Best practices for implementing SRS or another SPF forwarding solution
Hi! I'd like to implement SRS (or another solution that rewrites the envelope sender on forwarding) using a milter plugin or an SMTP based content filter. What are your experiences? Does anyone already use such a solution? Which plugins are you using? Thanks in advance, --leo -- e-mail ::: Leo.Bergolth (at) wu.ac.at fax ::: +43-1-31336-906050 location ::: IT-Services | Vienna University of Economics | Austria
Re: X-Original-To: and smtpd_proxy_filter
Jeroen Geilman wrote: On 12/28/10 7:58 AM, Alexander Moisseev wrote: m...@domain.tld has an alias al...@domain.tld and mail sent to alias. X-Original-To: al...@domain.tld prepends to the message. It's OK. If the before-queue content filter enabled as shown below then X-Original-To: is m...@domain.tld. Why did this happen? Stop resolving aliases in your before-queue content filter and the problem will go away. -o receive_override_options=no_unknown_recipient_checks You might want to set that to no_address_mappings for the smtpd proxy listener. Thanks. I was expanding aliases twice in before-queue and after-queue content filter. -- Alexander Moisseev
X-Original-To: and smtpd_proxy_filter
m...@domain.tld has an alias al...@domain.tld and mail sent to alias. X-Original-To: al...@domain.tld prepends to the message. It's OK. If the before-queue content filter enabled as shown below then X-Original-To: is m...@domain.tld. Why did this happen? I suppose it must be al...@domain.tld anyway. But if REDIRECT to other mailbox configured in header_checks (in addition to content filter) then X-Original-To: is al...@domain.tld as supposed. diff master.cf.bak master.cf 11a12,13 -o smtpd_proxy_filter=127.0.0.1:1125 -o smtpd_client_connection_count_limit=10 135a138,147 127.0.0.1:1025 inet n - n - - smtpd -o smtpd_authorized_xforward_hosts=127.0.0.0/8 -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions= -o mynetworks=127.0.0.0/8 -o receive_override_options=no_unknown_recipient_checks -- Thanks in advance, Alexander Moisseev
Re: postfix/local: Too many open files when opening .forward
On 09/24/2010 04:56 PM, Wietse Venema wrote: > Alexander 'Leo' Bergolth: >>> Even then, a 1000 recipient list should be spread across two local(8) >>> processes, each delivering transactions of 50 recipients side by side. >>> I don't see that happen, so I suspect the measurement is inconclusive. >> >> Unfortunately it doesn't. :-( > > Actually, multiple local(8) processes are used only when delivery > is slow enough. Ah - OK. > Now this 10ms delay in my first example (and your example) is > suspicious. I strongly suspect that my laptop disk drive has write > caching enabled. It is physically not possible to create a queue > file, fsync it, and then update a bunch of mailboxes and fsync them > when disk heads need to move. > > With this caching going on, my laptop delivers mail (and syslogs > to the same disk) as fast as memory can be written, so there is no > room left to run multiple processes delivering mail. > > On the other hand with my artificial 1000ms delays, there is plenty > of time for concurrency to pick up the slack. And that is what you > see happening in my second example. > > Does your mail server disk have write caching enabled, and is the > cache persistent when power fails? I suppose it does not fail that > often where you live, compared to this third-world infrastructure > in the USA that I live on. Yes, it has a battery backed write cache. But it's also connected to a UPS even though we almost never have power outages. (This once was a rescue coordination center. :-)) # hpacucli ctrl slot=0 show | grep -i -e "Write Cache" -e Battery Write Cache Size: 24 MB No-Battery Write Cache: Disabled Battery/Capacitor Count: 1 Battery/Capacitor Status: OK Cheers, --leo -- e-mail ::: Leo.Bergolth (at) wu.ac.at fax ::: +43-1-31336-906050 location ::: IT-Services | Vienna University of Economics | Austria
Re: postfix/local: Too many open files when opening .forward
On 09/24/2010 03:44 PM, Wietse Venema wrote: > Alexander 'Leo' Bergolth: >> On 09/24/2010 02:31 PM, Wietse Venema wrote: >>> Alexander 'Leo' Bergolth: >>>>> Have you already tried the "no RESET_OWNER_ATTR()" solution? >>>> >>>> I did a test run with the following aliases: >>>> >>>> testlist: member1, member2, leo2 >>>> owner-testlist: root >>>> member1: leo >>>> member2: testleo >>>> # leo2 is a real user >>>> >>>> It requeues the mail now. (Which is new.) There is one new queue-id for all >>>> the list-members and one local(8) process that delivers it: >>>> >>>> Sep 24 13:49:14 samba postfix/qmgr[3457]: 4096C2AEB8: from=, >>>> size=2011, nrcpt=1 (queue active) >>>> Sep 24 13:49:14 samba postfix/qmgr[3457]: 46761398CB: >>>> from=, size=2170, nrcpt=3 (queue active) >>>> Sep 24 13:49:14 samba postfix/local[3860]: 4096C2AEB8: >>>> to=, relay=local, delay=0.05, >>>> delays=0.02/0.02/0/0.02, dsn=2.0.0, status=sent (forwarded as 46761398CB) >>>> Sep 24 13:49:14 samba postfix/qmgr[3457]: 4096C2AEB8: removed >>>> Sep 24 13:49:14 samba postfix/local[3860]: 46761398CB: >>>> to=, relay=local, delay=0.02, delays=0.01/0/0/0, >>>> dsn=2.0.0, status=sent (delivered to mailbox) >>>> Sep 24 13:49:14 samba postfix/local[3860]: 46761398CB: >>>> to=, relay=local, delay=0.02, delays=0.01/0.01/0/0, >>>> dsn=2.0.0, status=sent (delivered to mailbox) >>> >>> This is expected behavior when >>> >>> - The local(8) process limit is set to 1 in master.cf, >>> >>> - The default_process_limit is set to 1 in main.cf, >>> >>> - Local deliveries are forced to be multi-recipient transactions >>> (_destination_recipient_limit > 1). >>> >>> None of the above is the recommended default. >> >> Hmm - strange - all parameters are correctly set: >> >> # grep ^local /etc/postfix/master.cf >> local unix - n n - - local >> >> # postconf default_process_limit \ >> local_destination_concurrency_limit \ >> local_destination_recipient_limit >> default_process_limit = 100 >> local_destination_concurrency_limit = 2 >> local_destination_recipient_limit = 1 >> >>> With the recommended default, the deliveries would be spread over >>> a small number of local(8) processes. Each process would deliver >>> one recipient per transaction, so that one recipient with an >>> expensive command in ~user/.forward would not slow down deliveries >>> for other users. >> >> With my parameters and yor explanation, I'd expect delivery to be >> distributed over 2 concurrent local(8) processes by the queue manager, >> each process delivering only to one local recipient. >> >> Did I get that right? > > Insufficient information. > > I don't know what changes you have been making in the course of > trouble shooting. For example you could have added another local > transport to master.cf with a different name, in which case the > _destination_recipient_limit would be the default of 50 recipients > per transaction. No. I didn't. There is only one local transport (the default). I did a postconf -n. There are no local_ or qmgr_ related settings that differ from the default. > Even then, a 1000 recipient list should be spread across two local(8) > processes, each delivering transactions of 50 recipients side by side. > I don't see that happen, so I suspect the measurement is inconclusive. Unfortunately it doesn't. :-( Cheers, --leo -- e-mail ::: Leo.Bergolth (at) wu.ac.at fax ::: +43-1-31336-906050 location ::: IT-Services | Vienna University of Economics | Austria
Re: postfix/local: Too many open files when opening .forward
On 09/24/2010 02:31 PM, Wietse Venema wrote: > Alexander 'Leo' Bergolth: >>> Have you already tried the "no RESET_OWNER_ATTR()" solution? >> >> I did a test run with the following aliases: >> >> testlist: member1, member2, leo2 >> owner-testlist: root >> member1: leo >> member2: testleo >> # leo2 is a real user >> >> It requeues the mail now. (Which is new.) There is one new queue-id for all >> the list-members and one local(8) process that delivers it: >> >> Sep 24 13:49:14 samba postfix/qmgr[3457]: 4096C2AEB8: from=, >> size=2011, nrcpt=1 (queue active) >> Sep 24 13:49:14 samba postfix/qmgr[3457]: 46761398CB: >> from=, size=2170, nrcpt=3 (queue active) >> Sep 24 13:49:14 samba postfix/local[3860]: 4096C2AEB8: >> to=, relay=local, delay=0.05, delays=0.02/0.02/0/0.02, >> dsn=2.0.0, status=sent (forwarded as 46761398CB) >> Sep 24 13:49:14 samba postfix/qmgr[3457]: 4096C2AEB8: removed >> Sep 24 13:49:14 samba postfix/local[3860]: 46761398CB: >> to=, relay=local, delay=0.02, delays=0.01/0/0/0, >> dsn=2.0.0, status=sent (delivered to mailbox) >> Sep 24 13:49:14 samba postfix/local[3860]: 46761398CB: >> to=, relay=local, delay=0.02, delays=0.01/0.01/0/0, >> dsn=2.0.0, status=sent (delivered to mailbox) > > This is expected behavior when > > - The local(8) process limit is set to 1 in master.cf, > > - The default_process_limit is set to 1 in main.cf, > > - Local deliveries are forced to be multi-recipient transactions > (_destination_recipient_limit > 1). > > None of the above is the recommended default. Hmm - strange - all parameters are correctly set: # grep ^local /etc/postfix/master.cf local unix - n n - - local # postconf default_process_limit \ local_destination_concurrency_limit \ local_destination_recipient_limit default_process_limit = 100 local_destination_concurrency_limit = 2 local_destination_recipient_limit = 1 > With the recommended default, the deliveries would be spread over > a small number of local(8) processes. Each process would deliver > one recipient per transaction, so that one recipient with an > expensive command in ~user/.forward would not slow down deliveries > for other users. With my parameters and yor explanation, I'd expect delivery to be distributed over 2 concurrent local(8) processes by the queue manager, each process delivering only to one local recipient. Did I get that right? Cheers, --leo -- e-mail ::: Leo.Bergolth (at) wu.ac.at fax ::: +43-1-31336-906050 location ::: IT-Services | Vienna University of Economics | Austria
Re: postfix/local: Too many open files when opening .forward
On 09/24/2010 03:07 PM, Alexander 'Leo' Bergolth wrote: > On 09/24/2010 02:31 PM, Wietse Venema wrote: >> Alexander 'Leo' Bergolth: >>>> Have you already tried the "no RESET_OWNER_ATTR()" solution? >>> >>> I did a test run with the following aliases: >>> >>> testlist: member1, member2, leo2 >>> owner-testlist: root >>> member1: leo >>> member2: testleo >>> # leo2 is a real user >>> >>> It requeues the mail now. (Which is new.) There is one new queue-id for all >>> the list-members and one local(8) process that delivers it: >> >> This is expected behavior when >> >> - The local(8) process limit is set to 1 in master.cf, >> - The default_process_limit is set to 1 in main.cf, >> - Local deliveries are forced to be multi-recipient transactions >> (_destination_recipient_limit > 1). > > Ah - that's the problem. > > # postconf local_destination_recipient_limit > local_destination_recipient_limit = 1 > >> None of the above is the recommended default. > > This IS the default: > > http://www.postfix.org/postconf.5.html#local_destination_recipient_limit Sorry. I mixed that up. local_destination_recipient_limit = 1 is the default and that's what you said. --leo -- e-mail ::: Leo.Bergolth (at) wu.ac.at fax ::: +43-1-31336-906050 location ::: IT-Services | Vienna University of Economics | Austria
Re: postfix/local: Too many open files when opening .forward
On 09/24/2010 02:31 PM, Wietse Venema wrote: > Alexander 'Leo' Bergolth: >>> Have you already tried the "no RESET_OWNER_ATTR()" solution? >> >> I did a test run with the following aliases: >> >> testlist: member1, member2, leo2 >> owner-testlist: root >> member1: leo >> member2: testleo >> # leo2 is a real user >> >> It requeues the mail now. (Which is new.) There is one new queue-id for all >> the list-members and one local(8) process that delivers it: > > This is expected behavior when > > - The local(8) process limit is set to 1 in master.cf, > - The default_process_limit is set to 1 in main.cf, > - Local deliveries are forced to be multi-recipient transactions > (_destination_recipient_limit > 1). Ah - that's the problem. # postconf local_destination_recipient_limit local_destination_recipient_limit = 1 > None of the above is the recommended default. This IS the default: http://www.postfix.org/postconf.5.html#local_destination_recipient_limit > With the recommended default, the deliveries would be spread over > a small number of local(8) processes. Each process would deliver > one recipient per transaction, so that one recipient with an > expensive command in ~user/.forward would not slow down deliveries > for other users. I see. I'll adjust that. With one local(8) process, requeuing wouldn't make any difference, the been_here table would fill just as much as without an owner- alias. Cheers, --leo -- e-mail ::: Leo.Bergolth (at) wu.ac.at fax ::: +43-1-31336-906050 location ::: IT-Services | Vienna University of Economics | Austria
Re: postfix/local: Too many open files when opening .forward
On 09/24/2010 12:42 PM, Wietse Venema wrote: > Alexander 'Leo' Bergolth: >> On 09/24/2010 01:26 AM, Wietse Venema wrote: >>> Alexander 'Leo' Bergolth: >>>> The other misfeature that I'd like to point out again is the behavior of >>>> been_here() when the hash table is full. >>> >>> The alternatives to a limited-size hash are a) run out of memory and >>> try to deliver mail repeatedly until it is too old or b) bounce >>> the excess recipients, neither of which wins a prize for beauty. > > Have you already tried the "no RESET_OWNER_ATTR()" solution? I did a test run with the following aliases: testlist: member1, member2, leo2 owner-testlist: root member1: leo member2: testleo # leo2 is a real user It requeues the mail now. (Which is new.) There is one new queue-id for all the list-members and one local(8) process that delivers it: Sep 24 13:49:14 samba postfix/qmgr[3457]: 4096C2AEB8: from=, size=2011, nrcpt=1 (queue active) Sep 24 13:49:14 samba postfix/qmgr[3457]: 46761398CB: from=, size=2170, nrcpt=3 (queue active) Sep 24 13:49:14 samba postfix/local[3860]: 4096C2AEB8: to=, relay=local, delay=0.05, delays=0.02/0.02/0/0.02, dsn=2.0.0, status=sent (forwarded as 46761398CB) Sep 24 13:49:14 samba postfix/qmgr[3457]: 4096C2AEB8: removed Sep 24 13:49:14 samba postfix/local[3860]: 46761398CB: to=, relay=local, delay=0.02, delays=0.01/0/0/0, dsn=2.0.0, status=sent (delivered to mailbox) Sep 24 13:49:14 samba postfix/local[3860]: 46761398CB: to=, relay=local, delay=0.02, delays=0.01/0.01/0/0, dsn=2.0.0, status=sent (delivered to mailbox) Sep 24 13:49:14 samba postfix/local[3860]: 46761398CB: to=, relay=local, delay=0.03, delays=0.01/0.01/0/0, dsn=2.0.0, status=sent (delivered to mailbox) Sep 24 13:49:14 samba postfix/qmgr[3457]: 46761398CB: removed Is this the intended behavior? (At least it looks the same if the list members are real users instead of aliases.) Cheers, --leo -- e-mail ::: Leo.Bergolth (at) wu.ac.at fax ::: +43-1-31336-906050 location ::: IT-Services | Vienna University of Economics | Austria
Re: postfix/local: Too many open files when opening .forward
On 09/24/2010 01:26 AM, Wietse Venema wrote: > Alexander 'Leo' Bergolth: >> The other misfeature that I'd like to point out again is the behavior of >> been_here() when the hash table is full. > > The alternatives to a limited-size hash are a) run out of memory and > try to deliver mail repeatedly until it is too old or b) bounce > the excess recipients, neither of which wins a prize for beauty. The most important action to take would be to print a big fat warning in the maillog if the table gets full (the limit is reached). Walking through a labyrinth of .forward files will in general end in a loop if you loose track of where you have already been. So I think bouncing the excess recipients and printing a big fat warning would indeed be the best way to solve that problem. If you continue, you will end up in subsequent errors like running out of filehandles, which a) obfuscates the real problem and b) will cause many other troubles. (If there are no filehandles available, not even the socket to the bounce or defer daemons can be opened anymore!) Cheers, --leo -- e-mail ::: Leo.Bergolth (at) wu.ac.at fax ::: +43-1-31336-906050 location ::: IT-Services | Vienna University of Economics | Austria
Re: postfix/local: Too many open files when opening .forward
On 09/23/2010 11:03 PM, Wietse Venema wrote: > Alexander 'Leo' Bergolth: >> OK, now I know why my messages are not requeued. >> >> First of all: The owner- alias IS REALLY set up correctly. :-) >> >> But if members of the list are aliases themselves, requeuing via cleanup >> won't work for them. Unfortunately, this is currently the case for my >> recipients. > > I mentioned before that you need an owner- alias for the "final" > alias when your aliases are nested. (Some of) the list _members_ are themselves represented as aliases. So the final alias that directly represents the list has the owner- alias. It isn't possible and it won't make any sense to add an owner- alias for every listmember. It's like the following aliases file: testlist: member1, member2 owner-testlist: root member1: leo member2: testleo You may argue that you already told me that in this case, the owner- alias isn't the final alias and thus it won't work. But that's bad. It should. The other misfeature that I'd like to point out again is the behavior of been_here() when the hash table is full. You praise postfix because "there is no such thing in Postfix as an overflow" but silently doing the wrong thing (simply not doing what the caller expects) will also cause very bad subsequent errors, namely a loop in this case. And this behavior has nothing to do with the reaction you intended: On 09/22/2010 07:06 PM, Wietse Venema wrote: > (there is no such thing in Postfix as an overflow; when memory runs > out, Postfix terminates the operation and tries later). Cheers, --leo -- e-mail ::: Leo.Bergolth (at) wu.ac.at fax ::: +43-1-31336-906050 location ::: IT-Services | Vienna University of Economics | Austria
Re: postfix/local: Too many open files when opening .forward
On 09/23/2010 03:48 PM, Victor Duchovni wrote: > On Thu, Sep 23, 2010 at 03:36:27PM +0200, Alexander 'Leo' Bergolth wrote: >> When the owner- alias IS configured correctly, HOW is delivery >> distributed to multiple processes? > > See the deliver_indirect() code. A new message is put in the queue, > via cleanup(8). The mail logs typically show: > > postfix/local[pid]: old-queue-id: to=, ... forwarded as > > > The code is in indirect.c and forward.c. OK, now I know why my messages are not requeued. First of all: The owner- alias IS REALLY set up correctly. :-) But if members of the list are aliases themselves, requeuing via cleanup won't work for them. Unfortunately, this is currently the case for my recipients. That's because deliver_switch() (with the correct owner- address set) first calls deliver_alias(), which resolves the alias (which in my case points to itself). But deliver_alias() also clears the owner attribute! Then control flow returns back to deliver_switch(), but the owner- address is still cleared. ... and the following condition won't match: 8< if (state.msg_attr.owner != 0 && strcasecmp(state.msg_attr.owner, state.msg_attr.user) != 0) return (deliver_indirect(state)); 8< Here is the control flow that leads to the problem: 8< deliver_recipient[9]: local rk recip lh...@example.com exten deliver an-a...@example.com exp_from rk been_here: recipient 9 lh...@example.com: 0 [...] owner: owner...@example.com ^^^ correctly set [...] deliver_switch[10]: local lhock recip lh...@example.com exten deliver an-a...@example.com exp_from rk deliver_alias[11]: local lhock recip lh...@example.com exten deliver an-a...@example.com exp_from rk -> finds lhock in ldap-aliases (lhock is an alias for itself) -> resets msg_attr.owner (calls RESET_OWNER_ATTR) deliver_resolve_tree[12]: local lhock recip lh...@example.com exten deliver an-a...@example.com exp_from lhock deliver_recipient[13]: local lhock recip lh...@example.com exten deliver an-a...@example.com exp_from lhock been_here: recipient 13 lh...@example.com: 0 [...] owner: null ^^^ owner is cleared now deliver_switch[14]: local lhock recip lh...@example.com exten deliver an-a...@example.com exp_from lhock deliver_alias[15]: local lhock recip lh...@example.com exten deliver an-a...@example.com exp_from lhock -> deliver_indirect() should be called here but owner is now null deliver_dotforward[15]: local lhock recip lh...@example.com exten deliver an-a...@example.com exp_from lhock 8< This means that requeuing via cleanup(8) doesn't work for destination addresses that are aliases. (Which is bad.) For those recipients, delivery is done by the same local(8) process, that's why I didn't see different queue ids. Cheers, --leo -- e-mail ::: Leo.Bergolth (at) wu.ac.at fax ::: +43-1-31336-906050 location ::: IT-Services | Vienna University of Economics | Austria
Re: postfix/local: Too many open files when opening .forward
On 09/23/2010 01:11 PM, Wietse Venema wrote: > Alexander 'Leo' Bergolth: >> However, I didn't notice any change such as separate processing of >> destination addresses. >> >> And I also cannot confirm that it uses a new queue id for each >> recipient. At which stage should the split happen? > > When the owner- alias is configured correctly, Postfix creates ONE > NEW queue file for ALL recipients in the alias. > > When the owner- alias is NOT configured correctly, ONE local(8) > PROCESS will attempt to deliver ALL recipients in the alias. When the owner- alias IS configured correctly, HOW is delivery distributed to multiple processes? Does it happen in deliver_switch() in recipient.c? 8< if (state.msg_attr.owner != 0 && strcasecmp(state.msg_attr.owner, state.msg_attr.user) != 0) return (deliver_indirect(state)); 8< If not - WHERE does it happen? --leo -- e-mail ::: Leo.Bergolth (at) wu.ac.at fax ::: +43-1-31336-906050 location ::: IT-Services | Vienna University of Economics | Austria
Re: postfix/local: Too many open files when opening .forward
On 09/23/2010 01:01 AM, Wietse Venema wrote: > Alexander 'Leo' Bergolth: >> Ah! The problem seems to be the duplicate_filter_limit! >> >> I set it to 1 and now everything works fine! > > For the last time, you really should use the proper owner- alias > when delivering mail to a list. Then, one local(8) process will > never attempt to deliver more than 1000 recipients. > > As notes in previous reply, the owner- alias is needed for > the "last" alias when you have nested ones. As stated before, I *DID* set up an owner- alias for the alias that resolves to all of the list-members. And this owner- alias seems to work (partly). The envelope address is set to owner-rk: The receiver sees the following header: Return-Path: ... and the verbose log file says: 8< maps_find: aliases: hash:/etc/aliases(0,lock|no_regsub|no_proxy|no_unauth|fold_fix): owner-rk = edvadmin, cgroeschl send attr address = owner-rk input attribute value: owner...@example.com rewrite_clnt: local: owner-rk -> owner...@example.com deliver_alias[7]: set owner attr: owner...@example.com sender: owner...@example.com owner: owner...@example.com 8< However, I didn't notice any change such as separate processing of destination addresses. And I also cannot confirm that it uses a new queue id for each recipient. At which stage should the split happen? Maybe it cannot create a new queue file on error because the filehandle limit is already reached? The verbose log says that it cannot connect to the bounce and the defer service: 8< warning: cannot open file /home/lhock/.forward: Too many open files deliver_mailbox[4039]: local lhock recip lh...@example.com exten deliver an-a...@example.com exp_from lhock been_here: mailbox lhock: 0 deliver_mailbox[4039]: set user_attr: lhock deliver_mailbox_file[4040]: local lhock recip lh...@example.com exten deliver an-a...@example.com exp_from lhock spool_uid/gid 1725/12 chown_uid/gid -1/-1 set_eugid: euid 1725 egid 12 set_eugid: euid 89 egid 89 connect to subsystem private/bounce: Too many open files connect to subsystem private/defer: Too many open files warning: AB5663FE62: defer service failure AB5663FE62: to=, relay=local, delay=98, delays=0.06/5.2/0/93, dsn=4.3.0, status=deferred (bounce or trace service failure) flush_add: site example.com id AB5663FE62 match_hostname: example.com ~? samba.intern.example.com match_hostname: example.com ~? localhost.example.com match_hostname: example.com ~? example.com connect to subsystem public/flush: Too many open files flush_add: site example.com id AB5663FE62 status -1 warning: AB5663FE62: flush service failure been_here: forward-done /home/lhock/.forward: 0 been_here: forward-done /home/lhock/.forward: 0 been_here: forward-done /home/lhock/.forward: 0 8< Cheers, --leo -- e-mail ::: Leo.Bergolth (at) wu.ac.at fax ::: +43-1-31336-906050 location ::: IT-Services | Vienna University of Economics | Austria
Re: postfix/local: Too many open files when opening .forward
On 09/22/2010 04:53 PM, Alexander 'Leo' Bergolth wrote:
> On 09/22/2010 01:22 AM, Wietse Venema wrote:
>> Alexander 'Leo' Bergolth:
>>> On 09/21/2010 10:57 PM, Wietse Venema wrote:
>>>> Alexander 'Leo' Bergolth:
>>>>> Since yesterday I am experiencing big problems when delivering mail to
>>>>> an alias-list. (Yes, I have set up an owner-listname alias. :-))
I have done another test-run with the environment variable EMAIL_VERBOSE
set.
>From the result I compared my own .forward-expansion (user abergolth)
and the first .forward that loops (user lhock).
$ grep -n "^been_here: forward " maillog-abergolth.txt
122:been_here: forward /home/abergolth/.forward: 0
235:been_here: forward /home/abergolth/.forward: 1
$ grep -n "^been_here: forward " maillog-lhock.txt
122:been_here: forward /home/lhock/.forward: 0
235:been_here: forward /home/lhock/.forward: 0
348:been_here: forward /home/lhock/.forward: 0
[...]
So maybe the problem is here:
8<
/*
* Do the duplicate check.
*/
if (htable_locate(dup_filter->table, lookup_key) != 0) {
status = 1;
} else {
if (dup_filter->limit <= 0
|| dup_filter->limit > dup_filter->table->used)
htable_enter(dup_filter->table, lookup_key, (char *) 0);
status = 0;
}
8<
Ah! The problem seems to be the duplicate_filter_limit!
I set it to 1 and now everything works fine!
But maybe the default behavior when the dup_filter->limit is reached
should be to print out an error and abort instead of quietly not
inserting it and thus looping on the first .forward that contains an
entry for \username?
Cheers,
--leo
--
e-mail ::: Leo.Bergolth (at) wu.ac.at
fax ::: +43-1-31336-906050
location ::: IT-Services | Vienna University of Economics | Austria
Re: postfix/local: Too many open files when opening .forward
On 09/22/2010 01:22 AM, Wietse Venema wrote: > Alexander 'Leo' Bergolth: >> On 09/21/2010 10:57 PM, Wietse Venema wrote: >>> Alexander 'Leo' Bergolth: >>>> Since yesterday I am experiencing big problems when delivering mail to >>>> an alias-list. (Yes, I have set up an owner-listname alias. :-)) >>> >>> Do you have the RIGHT owner-listname alias. >> >> This seems to be the problem. >> >> I have set up two owner- aliases, none of both seems to work... > > As documented, the owner-alias feature exists ONLY > IN main.cf:alias_maps NOT IN VIRTUAL ALIAS MAPS. You are talking about virtual alias maps as configured with the "virtual_alias_maps" config directive? I don't use them. I am using alias_maps: # postconf | grep ldap alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-aliases.cf, ldap:/etc/postfix/ldap-groups.cf My owner- address is defined in hash:/etc/aliases and my list address in ldap:/etc/postfix/ldap-groups.cf. Do both the list address and the owner- alias have to be in the same alias-map? >>> To avoid running out of file handles reduce the number of Postfix >>> processes or increase your kernel tables. >>> >>> http://www.postfix.org/postconf.5.html#default_process_limit >>> http://www.postfix.org/master.5.html >> >> I don't think that this should be a problem. default_process_limit is at >> 100 and there is virtually no load on the server. Could this setting >> really interfere with the local daemons behavior? > > If you run fewer local processes then **BIG SURPRISE** they > will use fewer file handles. The local(8) process is running into a *PER PROCESS* limit, not a user or system limit. (The system limit is 1182752.) Cheers, --leo -- e-mail ::: Leo.Bergolth (at) wu.ac.at fax ::: +43-1-31336-906050 location ::: IT-Services | Vienna University of Economics | Austria
Re: postfix/local: Too many open files when opening .forward
On 09/22/2010 05:20 PM, Wietse Venema wrote: > Alexander 'Leo' Bergolth: >> The file contains: >> 8< >> x...@gmail.com >> \lhock > > Your loop does not reproduce. I know. :( I don't think that the .forward file or its format are causing the problems. I can smoothly send mails directly to the users with the problematic .forward files. (Directly as opposed to sending via the list-address.) Maybe some kind of table overflow is causing the problems? I think the alias-list grew to a critical size, maybe some datastructure that is used e.g. for normalizing the destination addresses grew too big? I am using postfix-2.5.6. Where there significant code changes in this part of local(8)? Is there any debug mode that I can use to get some verbose output from local? Cheers, --leo -- e-mail ::: Leo.Bergolth (at) wu.ac.at fax ::: +43-1-31336-906050 location ::: IT-Services | Vienna University of Economics | Austria
