postfix pam_mysql authentication SHA512
postfix pam_mysql authentication SHA512/SHA256 on Feb 19, 2019; 10:53am In our postfix setup, we are using the pam_mysql module for SASL authentication from the MySQL database. (http://ryandoyle.net/posts/bringing-postfix-cyrus-sasl-saslauthd-pam_mysql_and_mysql_all_together/) We are using SHA512_CRYPT() for storing password using ENCRYPT() MySQL function. This works fine. However, ENCRYPT() function deprecated in MYSQL 8. Hence we are trying to figure out an alternative way to move the encryption from SHA512_CRYPT to SHA512 / SHA256 or similar Even though the pam_mysql github repo (https://github.com/NigelCunningham/pam-MySQL) supports SHA512, it's doesn't seem to be available in the latest release pam_mysql-0.8.1-0.22 Only other options available with the latest version of pam_mysql are a crypt, md5, and sha1. Since these are not good hashing algo's we don't want to use them. Also, we think using Dovecot backends for SASL authentication will create SPOFs and would like to keep postfix's SASL authentication independent of Dovecot. Please suggest an SASL authentication mechanism which we can use with postfix to authenticate the user with SHA512 or SHA256 (Not SHA512-CRYPT) from MySQL Database. postfix : main.cf smtpd_sasl_auth_enable = yes smtpd_sasl_path = smtpd cat /etc/sasl2/smtpd.conf pwcheck_method: saslauthd mech_list: plain login #log_level: 5 /etc/pam.d/smtp auth required pam_mysql.so user=mailuser passwd=pwd host=hostname db=dbname table=table-name usercolumn=user passwdcolumn=pwd crypt=1 debug account sufficient pam_mysql.so user=mailuser passwd=pwd host=hostname db=dbname table=table-name usercolumn=user passwdcolumn=email crypt=1 debug -- Sent from: http://postfix.1071664.n5.nabble.com/Postfix-Users-f2.html
Re: DKIM for locally generated mails - how best to approach?
Greetings, Viktor Dukhovni! >> There is no need to sign bounces for email that you don't receive >> but what about non-delivery notifications for mail that is accepted >> and then later found to be undeliverable? > In my multi-instance configurations, delivery failure to internal > recipients does not happen in the outbound output instance, and > the bad news travels outwards through that separate output > instance that does the signing. > Fragmenting Postfix into task-specific instances makes each > instance easier to manage, but requires some thought in the > initial design. It ultimately pays in non-trivial configurations, > but is probably not for everyone. It's already fragmented that way internally. Given the level of complication it takes to set up the mail server in present times, I don't see the need to waste any more effort than absolutely necessary to make it work. -- With best regards, Andrey Repin Tuesday, February 19, 2019 2:36:38 Sorry for my terrible english...
Re: Patch: 3.4.0-RC2 and 3.5 snapshots (was: DANE issue with postfix 3.4.0-RC2)
Viktor Dukhovni: > Do you want to do that now in a 3.4.0-RC3? Or save the cleanup > for 3.5? I wanted to understand why the code is "organized" as it is, as kinda sorta parallel worlds, instead of client-server style delegation. I understand that with the proposed code organization, we can release Postfix 3.4.0 responsibly (with some warts in the way we share SSL_CTX). But I also want to get this straightened out in Postfix 3.5, back to a simple remote call model that does support delegation, and with only explicit state sharing so that tlsproxy can handle different kinds of servers and clients. Wietse
Re: Patch: 3.4.0-RC2 and 3.5 snapshots (was: DANE issue with postfix 3.4.0-RC2)
On Mon, Feb 18, 2019 at 02:48:32PM -0500, Wietse Venema wrote: > > > Should we remove the those calls and make tls_pre_jail_init() a > > > mandatory call? > > > > I considered making the pre-jail init mandatory, but decided not > > to mess with posttls-finger, and left them in place. > > We should make tls_pre_jail_init() mandatory if that is the only > way to guarantee that shit won't blow up. Well, presently it is only the tlsproxy that looks at the TLS parameters before calling tls_client_init(). But it does call the pre-jail init first, and it does make sense to load all the parameters there. The likelihood of needing similar early access elsewhere seems low, but for the record I actually had the mandatory pre-jail init change done, before backing it out... So it is not a wild idea. > > The tls_dane_avail() function tests for and initializes optional > > library features, that are pre-requisites for DANE, but not necessarily > > for doing TLS generally. It is not a policy decision, but it is > > deferred until DANE is actually used for the first time. > > The Postfix SMTP client already decides if DANE is available. Why > is this needed again in tlsproxy? I see this as a problem in the > architecture if the tlsproxy client cannot simply delegate some TLS > library calls to the tlsproxy server. Modulo code upgrades without a restart, indeed the proxy and client should have equally capable libraries. So DANE could be "ready to go" (when available) in the proxy from the outset, by always enabling library support. With OpenSSL 1.0.0 and 1.0.1, we would often find incomplete support, and would not be able to report the reasons why DANE is not supported, if initialization is unconditional even for sites that don't enable outbound DANE> With OpenSSL 1.0.2, all the pre-requisites are there, so with a bit of refactoring, we could initialize the DANE TLS support unconditionally in tls_client_init(), so it is ready to run. We'd probably move the call to tls_dane_avail() into tls_client_start(), and fail there if the security level is DANE-based, but there's no DANE support. The tls_dane_avail() call would no longer be responsible for DANE initialization, it would just examine the memoized result. Do you want to do that now in a 3.4.0-RC3? Or save the cleanup for 3.5? -- Viktor.
Re: DKIM for locally generated mails - how best to approach?
> On Feb 18, 2019, at 2:51 PM, Wietse Venema wrote: > > There is no need to sign bounces for email that you don't receive > but what about non-delivery notifications for mail that is accepted > and then later found to be undeliverable? In my multi-instance configurations, delivery failure to internal recipients does not happen in the outbound output instance, and the bad news travels outwards through that separate output instance that does the signing. Fragmenting Postfix into task-specific instances makes each instance easier to manage, but requires some thought in the initial design. It ultimately pays in non-trivial configurations, but is probably not for everyone. -- Viktor.
Re: DKIM for locally generated mails - how best to approach?
Viktor Dukhovni: > On Mon, Feb 18, 2019 at 09:07:36PM +0300, Andrey Repin wrote: > > > > Maybe that should have finer granularity: it may be OK to inspect > > > bounces with Milters, but it may not be OK with header/body_checks. > > > > Yes, I see how this can be a problem. > > Is there a way around it? How are the bounces/notifications introduced to > > the queue? May be some parameter there could enable just the necessary > > processing? Or may be the queue itself could run the signer somehow? > > In a multi-instance configuration, with a network-facing input > instance that rejects bad input, and a null-client for local > submisison feeding an output instance for outbound mail that does > signing and the like, and an inbound instance that delivers to your > domains, the separation of duties makes it unnecessary to enable > signing on bounces. Perhaps that's more complex to initially > configure than you had in mind, but it is IMHO ultimately easier > to manage once configured, because of reduced conflict between the > requirements for the various flows. There is no need to sign bounces for email that you don't receive but what about non-delivery notifications for mail that is accepted and then later found to be undeliverable? Wietse
Re: PATCH: non-Postfix processes in init mode
Sure, I must suck at expressing myself as well. Not only had it been
left intact and moved into the conditional construct, it had still been
there without that in addition, thereby defeating the very purpose of
patching. Like I said, contrary to what I might seem, I'm no moron and
I've realized the mistake when You told me the behaviour didn't seem
like being patched in the first place. I've since then corrected my
patch, applied, compiled and packaged it, imaged it and am running it -
and it works. I'm grateful!
On 2019. 02. 18. 20:41, Wietse Venema wrote:
> Tam?s G?rczei:
>> Indeed, I should have had some rest before applying your patch... I did
>> create the condition, branching on init mode towards continue as
>> intended, yet also left the original call there right thereafter :D It
> You MUST KEEP the original panic call, like this:
>
> if ((proc = (MASTER_PROC *) binhash_find(master_child_table,
> (void *) &pid, sizeof(pid))) == 0) {
> if (init_mode)
> continue; /* non-Postfix process */
> msg_panic("master_reap: unknown pid: %d", pid);
> }
Re: Patch: 3.4.0-RC2 and 3.5 snapshots (was: DANE issue with postfix 3.4.0-RC2)
Viktor Dukhovni:
> On Mon, Feb 18, 2019 at 12:05:40PM -0500, Wietse Venema wrote:
>
> > > diff --git a/src/tls/tls_misc.c b/src/tls/tls_misc.c
> > > index 01dda8a97..a4a88a392 100644
> > > --- a/src/tls/tls_misc.c
> > > +++ b/src/tls/tls_misc.c
> > > @@ -772,6 +772,8 @@ voidtls_pre_jail_init(TLS_ROLE role)
> > > };
> > > int flags;
> > >
> > > +tls_param_init();
> >
> > tls_param_init() is already called by tls_client_init() and
> > tls_server_init().
>
> It turns out that it is possible to bypass the server one, and crash
> in the client init, by enabling server-side proxy TLS, but not
> configuring any certs. Then the tlsproxy client creates the params
> structure with as-yet unitialized parameters before calling the
> client init wrapper.
>
> > Should we remove the those calls and make tls_pre_jail_init() a
> > mandatory call?
>
> I considered making the pre-jail init mandatory, but decided not
> to mess with posttls-finger, and left them in place.
We should make tls_pre_jail_init() mandatory if that is the only
way to guarantee that shit won't blow up.
> > > --- a/src/tlsproxy/tlsproxy.c
> > > +++ b/src/tlsproxy/tlsproxy.c
> > > @@ -947,7 +947,12 @@ static int
> > > tlsp_client_start_pre_handshake(TLSP_STATE *state)
> > > {
> > > state->client_start_props->ctx = state->appl_state;
> > > state->client_start_props->fd = state->ciphertext_fd;
> > > -state->tls_context = tls_client_start(state->client_start_props);
> > > +if (!TLS_DANE_BASED(state->client_start_props->tls_level)
> > > + || tls_dane_avail())
> > > + state->tls_context = tls_client_start(state->client_start_props);
> >
> > How come that we need this here, when there is already code in the
> > Postfix SMTP client policy lookup that dedices whether a connection
> > will use DANE?
> >
> > Should we make the SMTP client responsible for policy decisions,
> > and make tlsproxy responsible for encryption, or should we randomly
> > distribute responsibilities across process boundaries?
>
> The tls_dane_avail() function tests for and initializes optional
> library features, that are pre-requisites for DANE, but not necessarily
> for doing TLS generally. It is not a policy decision, but it is
> deferred until DANE is actually used for the first time.
The Postfix SMTP client already decides if DANE is available. Why
is this needed again in tlsproxy? I see this as a problem in the
architecture if the tlsproxy client cannot simply delegate some TLS
library calls to the tlsproxy server.
Wietse
> We could do it unconditionally, and perhaps tone down any warnings,
> just saving the availability status. Then complain if DANE use
> is attempted later.
>
> --
> Viktor.
>
Re: PATCH: non-Postfix processes in init mode
Tam?s G?rczei:
> Indeed, I should have had some rest before applying your patch... I did
> create the condition, branching on init mode towards continue as
> intended, yet also left the original call there right thereafter :D It
You MUST KEEP the original panic call, like this:
if ((proc = (MASTER_PROC *) binhash_find(master_child_table,
(void *) &pid, sizeof(pid))) == 0) {
if (init_mode)
continue; /* non-Postfix process */
msg_panic("master_reap: unknown pid: %d", pid);
}
Re: DKIM for locally generated mails - how best to approach?
On Mon, Feb 18, 2019 at 09:07:36PM +0300, Andrey Repin wrote: > > Maybe that should have finer granularity: it may be OK to inspect > > bounces with Milters, but it may not be OK with header/body_checks. > > Yes, I see how this can be a problem. > Is there a way around it? How are the bounces/notifications introduced to > the queue? May be some parameter there could enable just the necessary > processing? Or may be the queue itself could run the signer somehow? In a multi-instance configuration, with a network-facing input instance that rejects bad input, and a null-client for local submisison feeding an output instance for outbound mail that does signing and the like, and an inbound instance that delivers to your domains, the separation of duties makes it unnecessary to enable signing on bounces. Perhaps that's more complex to initially configure than you had in mind, but it is IMHO ultimately easier to manage once configured, because of reduced conflict between the requirements for the various flows. -- Viktor.
Re: Patch: 3.4.0-RC2 and 3.5 snapshots (was: DANE issue with postfix 3.4.0-RC2)
On Mon, Feb 18, 2019 at 12:05:40PM -0500, Wietse Venema wrote:
> > diff --git a/src/tls/tls_misc.c b/src/tls/tls_misc.c
> > index 01dda8a97..a4a88a392 100644
> > --- a/src/tls/tls_misc.c
> > +++ b/src/tls/tls_misc.c
> > @@ -772,6 +772,8 @@ voidtls_pre_jail_init(TLS_ROLE role)
> > };
> > int flags;
> >
> > +tls_param_init();
>
> tls_param_init() is already called by tls_client_init() and
> tls_server_init().
It turns out that it is possible to bypass the server one, and crash
in the client init, by enabling server-side proxy TLS, but not
configuring any certs. Then the tlsproxy client creates the params
structure with as-yet unitialized parameters before calling the
client init wrapper.
> Should we remove the those calls and make tls_pre_jail_init() a
> mandatory call?
I considered making the pre-jail init mandatory, but decided not
to mess with posttls-finger, and left them in place.
> > --- a/src/tlsproxy/tlsproxy.c
> > +++ b/src/tlsproxy/tlsproxy.c
> > @@ -947,7 +947,12 @@ static int tlsp_client_start_pre_handshake(TLSP_STATE
> > *state)
> > {
> > state->client_start_props->ctx = state->appl_state;
> > state->client_start_props->fd = state->ciphertext_fd;
> > -state->tls_context = tls_client_start(state->client_start_props);
> > +if (!TLS_DANE_BASED(state->client_start_props->tls_level)
> > + || tls_dane_avail())
> > + state->tls_context = tls_client_start(state->client_start_props);
>
> How come that we need this here, when there is already code in the
> Postfix SMTP client policy lookup that dedices whether a connection
> will use DANE?
>
> Should we make the SMTP client responsible for policy decisions,
> and make tlsproxy responsible for encryption, or should we randomly
> distribute responsibilities across process boundaries?
The tls_dane_avail() function tests for and initializes optional
library features, that are pre-requisites for DANE, but not necessarily
for doing TLS generally. It is not a policy decision, but it is
deferred until DANE is actually used for the first time.
We could do it unconditionally, and perhaps tone down any warnings,
just saving the availability status. Then complain if DANE use
is attempted later.
--
Viktor.
Re: PATCH: non-Postfix processes in init mode
Indeed, I should have had some rest before applying your patch... I did
create the condition, branching on init mode towards continue as
intended, yet also left the original call there right thereafter :D It
applied and compiled well and I was sure I used the new packages and
image so I was reluctant to follow along. Now I have retraced my steps
and looked at the code after applying my mangled patch and everything
became very obvious. Thank You for pointing it out!
On 2019. 02. 18. 17:36, Wietse Venema wrote:
> Tam?s G?rczei:
>> 1 root 0:00 /usr/libexec/postfix/master -i
>> ...
>> 78 postfix 0:00 smtpd -n smtp -t inet -u -o stress=
>>
>> Feb 18 09:36:57 mail-postfix-0 postfix/master[1]: panic: master_reap:
>> unknown pid: 78*
>>> + if (init_mode)
>>> + continue; /* non-Postfix process */
>>> msg_panic("master_reap: unknown pid: %d", pid);
> You are not running a correctly patched master daemon. Your code
> probably looks like this:
>
> if (init_mode)
> msg_panic("master_reap: unknown pid: %d", pid);
>
> That is consistent with your logging and 'ps' output.
>
> Wietse
Re: DKIM for locally generated mails - how best to approach?
Greetings, Wietse Venema! > Andrey Repin: >> Greetings, All! >> >> I just discovered that mail generated locally (i.e. introduced by pickup >> daemon) is not signed. >> >> Digging in documentation, I've found >> http://www.postfix.org/postconf.5.html#non_smtpd_milters > That's what I use for signing this local submission. I understand that it's usable (it doesn't take much time to flip the switch and run sendmail to test, postconf is a wonderful tool!), but a note on its scope made me nervous. Though, if not using QMQP daemon, it seems harmless enough to use. >> And then there's rather old post on SO >> https://serverfault.com/a/547778/208335 >> which says that even if it's enabled, the reports generated by postfix itself >> will still not be signed. > I use 'internal_mail_filter_classes = bounce' for that. > Maybe that should have finer granularity: it may be OK to inspect > bounces with Milters, but it may not be OK with header/body_checks. Yes, I see how this can be a problem. Is there a way around it? How are the bounces/notifications introduced to the queue? May be some parameter there could enable just the necessary processing? Or may be the queue itself could run the signer somehow? -- With best regards, Andrey Repin Monday, February 18, 2019 21:00:01 Sorry for my terrible english...
Re: Patch: 3.4.0-RC2 and 3.5 snapshots (was: DANE issue with postfix 3.4.0-RC2)
Am 18.02.19 um 12:04 schrieb Viktor Dukhovni: > diff --git a/src/tls/tls_misc.c b/src/tls/tls_misc.c > diff --git a/src/tlsproxy/tlsproxy.c b/src/tlsproxy/tlsproxy.c Hello Viktor, I confirm these modifications fix the delivery failure. ... $ sendmail -f sen...@example.org -bv recipi...@gervers.com Feb 18 19:09:26 mail postfix/tlsproxy[10971]: CONNECT to [5.9.100.168]:25 Feb 18 19:09:26 mail postfix/tlsproxy[10971]: Verified TLS connection established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Feb 18 19:09:26 mail postfix/smtp[10969]: Verified TLS connection established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Feb 18 19:09:26 mail postfix/tlsproxy[10971]: DISCONNECT [5.9.100.168]:25 Feb 18 19:09:29 mail postfix/smtp[10969]: 443Bhj6rYCzyC: to=, relay=sys1.mmini.de[5.9.100.168]:25, delay=4, delays=0.1/0.04/0.47/3.4, dsn=2.1.5, status=deliverable (250 2.1.5 Ok) Feb 18 19:09:29 mail postfix/cleanup[10975]: 443Bhn6tnBzyS: message-id=<443bhn6tnb...@mail.example.org> Feb 18 19:09:30 mail postfix/bounce[10972]: 443Bhj6rYCzyC: sender delivery status notification: 443Bhn6tnBzyS ... > These address missing DANE and TLS library initialization in the > TLS proxy. Another issue remains, in that tlsproxy(8) wants > unconditional server-side support before it is willing to be a > client proxy, and therefore also wants server certificates. that's limitation I currently could tolerate :-) Thanks! Andreas
Re: Understanding pflogsumm "delivered" counter
Greetings, Bill Cole! > On 18 Feb 2019, at 10:30, Andrey Repin wrote: >> Greetings, All! >> >> I'm looking at the output of today's mail server activity and it does >> not add >> up. >> >> Per-Day Traffic Summary >> --- >> date received delivered deferredbounced >> rejected >> >> Feb 18 201919296 >> >> I could potentially understand 2x to 3x difference, but this is beyond >> my >> wildest expectations. >> The only mail multiplication rule I have is 1:2. > There are circumstances where you may receive a message for final > delivery or for relay with many recipients, each one of which requires > independent delivery. Thanks for your reply, but knowing my usual mail traffic, this is not the case. As I said, the only rule that could possibly multiply delivered counter is "info" virtual expanding into a list of managers (currently 2). But it seems unlikely it could produce 5-6x counter. 3x may be. Doing some totals, and matching against per-message reports, it seems it is counting both local and external mail as delivered, but there's no way to separate the two. I've counted 42 sent mails addresses (destinations) out of 342 "delivered". Combining with 26 received... That's not helpful at all. -- With best regards, Andrey Repin Monday, February 18, 2019 19:42:44 Sorry for my terrible english...
Re: Patch: 3.4.0-RC2 and 3.5 snapshots (was: DANE issue with postfix 3.4.0-RC2)
Viktor Dukhovni:
> On Mon, Feb 18, 2019 at 02:07:29AM -0500, Viktor Dukhovni wrote:
>
> > Feb 17 22:08:45 mail postfix/tlsproxy[23261]:
> > sys1.mmini.de[5.9.100.168]:25: depth=1 verify=0
> > subject=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
> >
> > These callbacks are NOT expected.
>
> diff --git a/src/tls/tls_misc.c b/src/tls/tls_misc.c
> index 01dda8a97..a4a88a392 100644
> --- a/src/tls/tls_misc.c
> +++ b/src/tls/tls_misc.c
> @@ -772,6 +772,8 @@ voidtls_pre_jail_init(TLS_ROLE role)
> };
> int flags;
>
> +tls_param_init();
tls_param_init() is already called by tls_client_init() and
tls_server_init().
Should we remove the those calls and make tls_pre_jail_init() a
mandatory call?
> diff --git a/src/tlsproxy/tlsproxy.c b/src/tlsproxy/tlsproxy.c
> index 2c8714cb4..91eb4a9bc 100644
> --- a/src/tlsproxy/tlsproxy.c
> +++ b/src/tlsproxy/tlsproxy.c
> @@ -947,7 +947,12 @@ static int tlsp_client_start_pre_handshake(TLSP_STATE
> *state)
> {
> state->client_start_props->ctx = state->appl_state;
> state->client_start_props->fd = state->ciphertext_fd;
> -state->tls_context = tls_client_start(state->client_start_props);
> +if (!TLS_DANE_BASED(state->client_start_props->tls_level)
> + || tls_dane_avail())
> + state->tls_context = tls_client_start(state->client_start_props);
How come that we need this here, when there is already code in the
Postfix SMTP client policy lookup that dedices whether a connection
will use DANE?
Should we make the SMTP client responsible for policy decisions,
and make tlsproxy responsible for encryption, or should we randomly
distribute responsibilities across process boundaries?
Wietse
Re: DKIM for locally generated mails - how best to approach?
Andrey Repin: > Greetings, All! > > I just discovered that mail generated locally (i.e. introduced by pickup > daemon) is not signed. > > Digging in documentation, I've found > http://www.postfix.org/postconf.5.html#non_smtpd_milters That's what I use for signing this local submission. > And then there's rather old post on SO https://serverfault.com/a/547778/208335 > which says that even if it's enabled, the reports generated by postfix itself > will still not be signed. I use 'internal_mail_filter_classes = bounce' for that. Maybe that should have finer granularity: it may be OK to inspect bounces with Milters, but it may not be OK with header/body_checks. Wietse
Re: PATCH: non-Postfix processes in init mode
Tam?s G?rczei:
> 1 root 0:00 /usr/libexec/postfix/master -i
>...
> 78 postfix 0:00 smtpd -n smtp -t inet -u -o stress=
>
> Feb 18 09:36:57 mail-postfix-0 postfix/master[1]: panic: master_reap:
> unknown pid: 78*
> > + if (init_mode)
> > + continue; /* non-Postfix process */
> > msg_panic("master_reap: unknown pid: %d", pid);
You are not running a correctly patched master daemon. Your code
probably looks like this:
if (init_mode)
msg_panic("master_reap: unknown pid: %d", pid);
That is consistent with your logging and 'ps' output.
Wietse
Re: Logging change with Postfix 3.4.0-RC2
Quite right. My mistake. The root cause in this case was musl libc in the Alpine Linux 3.9 container image, whose syslog call uses dgram only, unlike glibc, which will attempt stream as well. Thanks for pointing me in the right direction. FWIW, the new CHUNKING support (BDAT command) in Postfix 3.4 works exactly as expected. Thanks for adding it. Cheers, -Lex On Fri, Feb 15, 2019 at 5:09 AM Wietse Venema wrote: > Lex Scarisbrick: > > The 3.4.0-RC2 version of Postfix appears to have dropped support for > > logging via TCP Unix sockets. As recently as 3.3.0 Postfix used a TCP > Unix > > socket to connect to syslog. This is obliquely referenced in the release > > notes: > > Postfix calls the syslog(3) system library function, so if anything > has changed there, complain to your vendor. > > Wietse >
Re: Support for "Linux 5"
* Wietse Venema: > What distribution runs Linux 5 kernels? I would like to do a smoke > test for due diligence (does it build and run). Gentoo Linux makes new kernels available as un-stable (*) flagged ebuilds as soon as the kernels are officially released. -Ralph (*) The mailing list filter won't let me send this adjective without a dash. :-P
Re: Understanding pflogsumm "delivered" counter
On 18 Feb 2019, at 10:30, Andrey Repin wrote: Greetings, All! I'm looking at the output of today's mail server activity and it does not add up. Per-Day Traffic Summary --- date received delivered deferredbounced rejected Feb 18 201919296 I could potentially understand 2x to 3x difference, but this is beyond my wildest expectations. The only mail multiplication rule I have is 1:2. There are circumstances where you may receive a message for final delivery or for relay with many recipients, each one of which requires independent delivery. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Available For Hire: https://linkedin.com/in/billcole
Understanding pflogsumm "delivered" counter
Greetings, All! I'm looking at the output of today's mail server activity and it does not add up. Per-Day Traffic Summary --- date received delivered deferredbounced rejected Feb 18 201919296 I could potentially understand 2x to 3x difference, but this is beyond my wildest expectations. The only mail multiplication rule I have is 1:2. -- With best regards, Andrey Repin Monday, February 18, 2019 18:23:28 Sorry for my terrible english...
Re: PATCH: non-Postfix processes in init mode
So I've now configured init mode in foreground with logging properly on
stdout and your patch applied to the last 3.5 snapshot and I got the
same panic, although this time not against my piped spamd process,
rather smtpd, it would appear:
/ # ps
PID USER TIME COMMAND
1 root 0:00 /usr/libexec/postfix/master -i
75 postfix 0:00 pickup -l -t unix -u
76 postfix 0:00 qmgr -l -t unix -u
77 postfix 0:00 postlogd -l -n postlog -t unix-dgram -u
* 78 postfix 0:00 smtpd -n smtp -t inet -u -o stress=*
79 postfix 0:00 tlsmgr -l -t unix -u
80 postfix 0:00 anvil -l -t unix -u
81 postfix 0:00 trivial-rewrite -n rewrite -t unix -u
82 postfix 0:00 spawn -z -n policyd-spf -t unix user=policyd-spf
argv=/usr/bin/policyd-spf /policyd-spf/config/policyd-spf.conf
83 policyd- 0:01 {policyd-spf} /usr/bin/python3.6
/usr/bin/policyd-spf /policyd-spf/config/policyd-spf.conf
84 postfix 0:00 cleanup -z -t unix -u
85 postfix 0:00 pipe -n spamassassin -t unix user=spamc
argv=/usr/bin/spamc -d mail-spamassassin-0.mail-spamassassin-service -e
/usr/sbin/sendmail -oi -f ${sender} ${recipient}
89 postfix 0:00 lmtp -t unix -u
90 root 0:00 /bin/sh
97 root 0:00 ps
/ # command terminated with exit code 137
tgerczei@altar ~ $ kc logs po/mail-postfix-0 -f
Feb 18 09:33:39 mail-postfix-0 postfix/postfix-script[63]: warning:
group or other writable: /postfix/config-live/.
Feb 18 09:33:39 mail-postfix-0 postfix/postfix-script[74]: starting the
Postfix mail system
Feb 18 09:33:39 mail-postfix-0 postfix/master[1]: daemon started --
version 3.5-20190212, configuration /postfix/config-live
Feb 18 09:35:14 mail-postfix-0 postfix/smtpd[78]: connect from
mail-qt1-f182.google.com[209.85.160.182]
Feb 18 09:35:15 mail-postfix-0 postfix/smtpd[78]: Anonymous TLS
connection established from mail-qt1-f182.google.com[209.85.160.182]:
TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Feb 18 09:35:15 mail-postfix-0 postfix/smtpd[78]: NOQUEUE: filter: RCPT
from mail-qt1-f182.google.com[209.85.160.182]:
: Sender address triggers FILTER
spamassassin:dummy; from= to=
proto=ESMTP helo=
Feb 18 09:35:17 mail-postfix-0 postfix/smtpd[78]: 63C912D0E6C:
client=mail-qt1-f182.google.com[209.85.160.182]
Feb 18 09:35:17 mail-postfix-0 postfix/cleanup[84]: 63C912D0E6C:
message-id=
Feb 18 09:35:17 mail-postfix-0 postfix/qmgr[76]: 63C912D0E6C:
from=, size=2872, nrcpt=1 (queue active)
Feb 18 09:35:17 mail-postfix-0 postfix/smtpd[78]: disconnect from
mail-qt1-f182.google.com[209.85.160.182] ehlo=2 starttls=1 mail=1 rcpt=1
bdat=1 quit=1 commands=7
Feb 18 09:35:27 mail-postfix-0 postfix/pickup[75]: DBB5F2D0E71: uid=103
from=
Feb 18 09:35:27 mail-postfix-0 postfix/pipe[85]: 63C912D0E6C:
to=, relay=spamassassin, delay=13,
delays=2.2/0.02/0/10, dsn=2.0.0, status=sent (delivered via spamassassin
service)
Feb 18 09:35:27 mail-postfix-0 postfix/qmgr[76]: 63C912D0E6C: removed
Feb 18 09:35:27 mail-postfix-0 postfix/cleanup[84]: DBB5F2D0E71:
message-id=
Feb 18 09:35:29 mail-postfix-0 postfix/qmgr[76]: DBB5F2D0E71:
from=, size=3497, nrcpt=1 (queue active)
Feb 18 09:35:29 mail-postfix-0 postfix/lmtp[89]: DBB5F2D0E71:
to=,
relay=mail-dovecot-0.mail-dovecot-service.default.svc.cluster.local[10.244.1.53]:54321,
delay=2.9, delays=2.7/0.03/0.05/0.12, dsn=2.0.0, status=sent (250 2.0.0
y4PZF2F8alx7GwAAHo2YKg Saved)
Feb 18 09:35:29 mail-postfix-0 postfix/qmgr[76]: DBB5F2D0E71: removed
*Feb 18 09:36:57 mail-postfix-0 postfix/master[1]: panic: master_reap:
unknown pid: 78*
I don't get this since smtpd had surely been spawned by master. Should I
have used 3.4? Does 3.5 have anything new in there in this regard?
(Anything below 3.4 wouldn't support logging to stdout, hence my choice.)
On 2019. 02. 17. 15:42, Wietse Venema wrote:
> Wietse Venema:
>> Tam?s G?rczei:
>>> Hello List,
>>>
>>> I'd like to ask whether You're aware of any change which might cause
>>> breakage in my setup involving spamc with a completely unchanged
>>> configuration in between - I'm getting the following error:
>>>
>>> *"panic: master_reap: unknown pid"*
>> Is the Postfix master daemon running as PID 1? Historically this
>> PID was reserved for the init daemon which becomes the parent of
>> orphaned processes, i.e. processes that terminate without a parent
>> waiting for them. Postfix does not create such processes, but if
>> you run other programs inside the Postfix container then they
>> might do that.
>>
>> Options:
>>
>> - Run Postfix as PID != 1.
>>
>> - Don't co-locate Postfix with other software. That means pipe into
>> socket instead of into a program in the same container.
>>
>> - Make the master sloppier, and accept events from processes that
>> it did not create.
> As per the patch below.
>
> --- src/master/master_spawn.c-2014-12-06 20:35:33.0 -0500
> +++ src/master/master_spawn.c 2019-02-17 09:38:52.0 -0500
> @@ -301,8 +301,11 @@
> if (msg_verbose)
> msg_info("master_reap_child: pid %
Re: Slowness after upgrading from postfix 2.x to 3.1.8
On Fri, 2019-02-15 at 20:42 +0100, Christopher R. Gabriel wrote: > > > > Is the "delay" recorded in a typical Postfix log entry ? > > > > Stolen from Postfix 2.3.19: > > > > Postfix logs additional delay information as "delays=a/b/c/d" > > > > where a=time before queue manager, including message > > transmission; > > > > b=time in queue manager; c=connection setup time including > > DNS, > > > > HELO and TLS; d=message transmission time. > > > > > > yes, that's from where I get such data from, like > > > > > > delay=31, delays=30/0/0.33/1.1, > > > > Can you strace the opendkim process? Is it hanging in DNS lookups? > > > > Wietse > > It's in signing mode only, and we I try to strace it (with follow > option for thread) it crashes. After being able to spend sometime doing perf and strace on the opendkim process, I was able to find out that the underlying NSS stack configuration (nscd + nslcd) was causing the bottleneck. After removing the cache and the LDAP backend (which is a default, but fortunately not mandatory for us), delays got aligned with servers using the old stack (postfix 2.x etc). So they're really to blame, by now I was able to remove the cause of the symptom (semi cit.) Is anyone running the same nss stack without problems? Christopher
Re: Expires Header(RFC-5536) implementation
azusa_tar...@yahoo.co.jp: > Hi, > I'm trying to implement "Expires" header (Defined by RFC-5536). > I want Postfix bounce the expired mails. > At first, I use content filter to check Expires date is valid. > > However, content filtering can be done only one time when into the mail queue. > (It can't be done when Postfix resend deferred emails) Extract the expiration time from the header and store it as 'named attribute', just like MAIL_ATTR_ENCODING. Then have the queue manager read it ffrom queue file just like MAIL_ATTR_ENCODING. You may want to do some sanity checks such that Postfix will not accept mail that is already expired. Wietse
Re: DKIM for locally generated mails - how best to approach?
On Mon, 18 Feb 2019 at 10:51, Andrey Repin wrote: > I just discovered that mail generated locally (i.e. introduced by pickup > daemon) is not signed. > > Digging in documentation, I've found > http://www.postfix.org/postconf.5.html#non_smtpd_milters > But its description made me reluctant to enable it straight away. > > And then there's rather old post on SO https://serverfault.com/a/547778/208335 > which says that even if it's enabled, the reports generated by postfix itself > will still not be signed. > > Is there a recommended way of solving this? Using non_smtpd_milters works fine for me. I'm not sure about the reports issue, but try to ensure that they are not sent from an address that is subject to DMARC restrictions.
Re: Support for "Linux 5"
> > What distribution runs Linux 5 kernels? I would like to do a smoke > test for due diligence (does it build and run). Arch Linux will have Linux 5 when the kernel comes out. Bjoern
Patch: 3.4.0-RC2 and 3.5 snapshots (was: DANE issue with postfix 3.4.0-RC2)
On Mon, Feb 18, 2019 at 02:07:29AM -0500, Viktor Dukhovni wrote:
> Feb 17 22:08:45 mail postfix/tlsproxy[23261]:
> sys1.mmini.de[5.9.100.168]:25: depth=1 verify=0
> subject=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
>
> These callbacks are NOT expected.
diff --git a/src/tls/tls_misc.c b/src/tls/tls_misc.c
index 01dda8a97..a4a88a392 100644
--- a/src/tls/tls_misc.c
+++ b/src/tls/tls_misc.c
@@ -772,6 +772,8 @@ voidtls_pre_jail_init(TLS_ROLE role)
};
int flags;
+tls_param_init();
+
/* Nothing for clients at this time */
if (role != TLS_ROLE_SERVER)
return;
diff --git a/src/tlsproxy/tlsproxy.c b/src/tlsproxy/tlsproxy.c
index 2c8714cb4..91eb4a9bc 100644
--- a/src/tlsproxy/tlsproxy.c
+++ b/src/tlsproxy/tlsproxy.c
@@ -947,7 +947,12 @@ static int tlsp_client_start_pre_handshake(TLSP_STATE
*state)
{
state->client_start_props->ctx = state->appl_state;
state->client_start_props->fd = state->ciphertext_fd;
-state->tls_context = tls_client_start(state->client_start_props);
+if (!TLS_DANE_BASED(state->client_start_props->tls_level)
+ || tls_dane_avail())
+ state->tls_context = tls_client_start(state->client_start_props);
+else
+ msg_warn("%s: DANE requested, but not available",
+state->client_start_props->namaddr);
if (state->tls_context != 0)
return (TLSP_STAT_OK);
These address missing DANE and TLS library initialization in the
TLS proxy. Another issue remains, in that tlsproxy(8) wants
unconditional server-side support before it is willing to be a
client proxy, and therefore also wants server certificates.
We should probably split its pre_jail initialization into separate
client-side and server-side functions, so that the server side can
return with nothing to do, and yet allow the client side to be
activated. And presumably the converse, and then turn away unsupported
requests from servers or clients at run-time, if the corresponding
feature is not enabled.
--
Viktor.
DKIM for locally generated mails - how best to approach?
Greetings, All! I just discovered that mail generated locally (i.e. introduced by pickup daemon) is not signed. Digging in documentation, I've found http://www.postfix.org/postconf.5.html#non_smtpd_milters But its description made me reluctant to enable it straight away. And then there's rather old post on SO https://serverfault.com/a/547778/208335 which says that even if it's enabled, the reports generated by postfix itself will still not be signed. Is there a recommended way of solving this? -- With best regards, Andrey Repin Monday, February 18, 2019 13:22:57 Sorry for my terrible english...
