Re: One certificate per port

[G. Schlisio]

>> Thank you for your hints and sorry for the late followup. busy and stuff.
>> thank you for your suggestions, I was aware of the csr-option but wanted
>> to avoid this, since it does not well automate with certbot.
> 
> Sine "--csr" is a certbot option I am surprised to hear you say that
> "it does not automate well".  My expectation is that this is fairly
> easy to automate.  Just generate the CSR from a fixed private key,
> and use it instead of having certbot generate a new key and the
> corresponding CSR.  Perhaps you need help running "openssl req"
> in non-interactive batch scripts?

Yes you are righ, it should work. Maybe some tweaks needed to not use
the same csr for all domains (just needed for the email handling
domain), but i like the other option better.

>> I came up with another idea, which is pinning the intermediate
>> certificate with a 2 1 1 TLSA entry.
> 
> That's exactly what I recommend to LE users.
> 
>> Even though this is not totally correct (2 means private CA, which is
>> not true in this case) it seemed to work.
> 
> Actually it is completely correct.  Usage DANE-TA(2) just lifts the
> requirement of pre-existing client trust of the designated CA.  It
> is completely valid for the CA in question to also be a public CA
> trusted by some clients.
> 
>> Do you see any issues with doing this?
> 
> None, provided you trust Let's Encrypt to be your CA and to not
> issue certificates for your domain to the wrong party.
> 

thanks for your fast reply, this list makes postfix even more valuable
than it already is.

best
georg

Re: One certificate per port

[G. Schlisio]

> 
>> On Apr 6, 2017, at 5:02 PM, G. Schlisio <g.schli...@dukun.de> wrote:
>>
>> I wonder if it is possible to have one cert per port postfix is serving
>> on, eg one for 25 and one for 587.
> 
> Yes.
> 
>master.cf:
>  submission inet ... smtpd
>-o smtpd_tls_cert_file=$mua_tls_cert_file
>-o smtpd_tls_key_file=$mua_tls_key_file
> 
>main.cf:
>   # Inbound MX certificate and key in a single file
>   smtpd_tls_cert_file = ...
> 
>   # Submission certificate and key in a single file
>   mua_tls_cert_file = ...
>   mua_tls_key_file = $mua_tls_cert_file
> 
>>
>> Background of this:
>> for user interaction (mainly on port 587) I would like to use my signed
>> letsencrypt cert which changes fairly often.
>> For interaction of servers I would like to use DANE, and so a long-lifed
>> self-signed certificate would be beneficial to not break during
>> automated renewal and avoid frequent rollovers.
> 
> It is also possible to avoid DANE TLSA changes while rolling over
> Let's Encrypt keys:
> 
>
> http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436.html#a86444
>https://community.letsencrypt.org/t/new-certbot-client-and-csr-option/15766
>
> https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/
>
> https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022
> 

thank you for your hints and sorry for the late followup. busy and stuff.
thank you for your suggestions, I was aware of the csr-option but wanted
to avoid this, since it does not well automate with certbot.

I came up with another idea, which is pinning the intermediate
certificate with a 2 1 1 TLSA entry.
Even though this is not totally correct (2 means private CA, which is
not true in this case) it seemed to work.
Do you see any issues with doing this?
Thanks in advance.
Georg

One certificate per port

[G. Schlisio]

Hi all,

I wonder if it is possible to have one cert per port postfix is serving
on, eg one for 25 and one for 587.

Background of this:
for user interaction (mainly on port 587) I would like to use my signed
letsencrypt cert which changes fairly often.
For interaction of servers I would like to use DANE, and so a long-lifed
self-signed certificate would be beneficial to not break during
automated renewal and avoid frequent rollovers.

I hope my assumptions are correct.
Feedback much appreciated.

Thank you in advance
Georg

Re: Postfix delivery problem

[G. Schlisio]

> I managed to find where this is happening. It is not in glibc but in
> systemd.
> 
> If your /etc/nsswitch.conf has something like this:
> 
> passwd: compat mymachines systemd
> 
> then the routines that are being used are systemd ones.
> 
> The checks being done are here in the function valid_user_group_name:
> 
> https://github.com/systemd/systemd/blob/master/src/basic/user-util.c
> 
> and in the case that those checks fail then _nss_systemd_getpwnam_r from
> systemd libraries returns EINVAL
> 
> https://github.com/systemd/systemd/blob/master/src/nss-systemd/nss-systemd.c
> 
> if (!valid_user_group_name(name)) {
> r = -EINVAL;
> goto fail;
> }
> 
> ...
> 
> fail:
> *errnop = -r;
> return NSS_STATUS_UNAVAIL;
> 
> So the problem is that systemd version of getpwnam_r is deviating from
> the standard of returning 0 for not found users.
> 
> Either the systemd library module or the nsswitch.conf is probably what
> changed during your upgrade.
> 
> John

hi john,

both packages (filesystem containing nsswitch.conf and systemd) received
an upgrade last week:
upgraded systemd (231-4 -> 232-6)
diff of old vs new nsswitch.conf:

$ diff {,/}etc/nsswitch.conf
3,5c3,5
< passwd: files
< group: files
< shadow: files
---
> passwd: compat mymachines systemd
> group: compat mymachines systemd
> shadow: compat
9c9
< hosts: files dns myhostname
---
> hosts: files mymachines resolve [!UNAVAIL=return] dns myhostname

so i might take this to the arch ML and also to the systemd bug tracker.

thank you for your thorough investigation of this isssue!
georg

Re: Postfix delivery problem

[G. Schlisio]

> 
> I tried that on archlinux. The above program still produces EINVAL for
> login names between 32 and 255 inclusive.
> 
> _SC_LOGIN_NAME_MAX is 256 on that platform.
> 
> John
> 

hi,

earlier i tried with literal "AA", which was probably not what you
meant.
it produced a "not found".
using an affected user name yields (with both your programs):
getpwnam_r: Invalid argument
while an existing shell account yields its UID:
Name: ; UID: 1001

for me its not clear whats the difference between a literal  string
and an existing username not in passwd (why one produces an error and
one doesnt).

sorry for not reading carefully earlier…

georg

Re: Postfix delivery problem

[G. Schlisio]

> Georg
> 
> I don't think there is enough evidence at the moment to say with
> certainty that any change in glibc has introduced the problem, since you
> were using that for a while now without seeing issues.
> 
> I'd still be interested in knowing what output the test program gives on
> the affected server. 
> 
> best wishes to you too.
> 
> John

oh, right, the test program.

me@dukun ~ > ./test2 
Not found
me@dukun ~ > echo $?
1

i hope this is the information you looked for? i didnt think about it
too much at the moment…
georg

Re: Postfix delivery problem

[G. Schlisio]

Am 24.12.2016 um 08:40 schrieb John Fawcett:
> On 12/24/2016 01:19 AM, Wietse Venema wrote:
>> John Fawcett:
> "On success, *getpwnam_r*() and *getpwuid_r*() return zero, and set
> /*result/ to /pwd/. If no matching password record was found, these
> functions return 0 and store NULL in /*result/. In case of error, an
> error number is returned, and NULL is stored in /*result/. "
>> A zero result value mans that no error occurred; we know for certain
>> that the user exists or does not exist.
>>
>> That's almost consistent with, for example, the XOPEN standard: \
>>
>> The getpwnam_r() function shall return zero on success or if
>> the requested entry was not found AND NO ERROR HAS OCCURRED.
>> If an error has occurred, an error number shall be returned to
>> indicate the error.
>>
>> What bugs me is the text that follows later in that same Linux
>> manpage:
>>
>> ERRORS
>>
>>0 or ENOENT or ESRCH or EBADF or EPERM or ...
>>   The given name or uid was not found.
>>
>> This text makes no sense. It is in conflict with XOPEN, and with
>> the other quote from the Linux manpage.
>>
>>  Wietse
>>
> Yes, at first I read the text under ERRORS as though it was part of the
> standard, but then I realized that it is just stating what some
> implementations do in practice (which is what makes no sense).
> 
> John

very interesting ideed. i took it to the arch mailing list [0], maybe we
dig up there what changed recently with the glibc behaviour.
atm the mailing list is on chrismas hibernation but that might change at
some point.
thank you a lot for your help and information and have a nice christmas!

georg

Re: Postfix delivery problem

[G. Schlisio]

> Georg
> 
> Replying to my own post: on re-reading the specification, it looks clear
> 
> "On success, *getpwnam_r*() and *getpwuid_r*() return zero, and set
> /*result/ to /pwd/. If no matching password record was found, these
> functions return 0 and store NULL in /*result/. In case of error, an
> error number is returned, and NULL is stored in /*result/. "
> 
> So it's the various implementations that may be deviating from this:
> 
> "Experiments on various UNIX-like systems show that lots of different
> values occur in this situation: 0, ENOENT, EBADF, ESRCH, EWOULDBLOCK,
> EPERM and probably others."
> 
> In the case reported it is returning EINVAL (invalid argument). What
> version of glibc are you using?
> 
> John
> 

we are running the glibc 2.24 from the official archlinux repository,
last rebuild of glibc happened in early august this year and was no part
of the update in question.
georg

Re: Postfix delivery problem

[G. Schlisio]

> It was worth checking the obvious to exclude it.
> 
> I suspect that one of the system libraries used by the .forward
> mechanism has been impacted by your upgrade.
> 
> If you don't need to use .forward files you might try setting
> 
> forward_path =
> 
> in main.cf and restart postfix. If that solves it,  then there is
> something wrong outside postfix.
> 
> John

YAY, that fixed it. sendmail -bv reports delivery to dovecot.

what was the exact error then and how can i avoid this in the future?
just point me to the topics to read, so i dont eat more of your time
helping other people with mailing problems or preparing christmas or
whatever. your fast and precise help is very much appreciated!

best regards
georg

Re: Postfix delivery problem

[G. Schlisio]

Am 23.12.2016 um 15:11 schrieb John Fawcett:
> On 12/23/2016 01:56 PM, G. Schlisio wrote:
>>> Couldn't find the postconf -n output at that link
>> sorry, correct link for postconf -n: http://termbin.com/w509
> 
> It doesn't look like "local" is even attempting to open the
> mailbox_transport_maps file. That's a good indication that the config
> file you posted is not being used by your running postfix instance. An
> obvious reason that might be is if main.cf has been changed but postfix
> has not been restarted. Another reason might be that a different
> configuration directory is being used. You can check that because when
> postfix starts it logs a message about which configuration directory is
> used.

sorry, but i restarted postfix multiple times, even did a full reboot of
the machine right after the system update.
at startup the correct config is loaded:
postfix/master[4750]: daemon started -- version 3.1.3, configuration
/etc/postfix

also, statements about the "mailinglists" are printed, so this is a
strong indication the right config is read.

what else could block local from opening the mailbox_transport_maps?
local runs as root (i suppose?), and the mailbox_transport_maps
(rehashed several times now) has 644 properties.

georg

Re: Postfix delivery problem

[G. Schlisio]

> Couldn't find the postconf -n output at that link

sorry, correct link for postconf -n: http://termbin.com/w509

Re: Postfix delivery problem

[G. Schlisio]

> Hi Georg
> 
> for reporting problems you can refer to
> http://www.postfix.org/DEBUG_README.html#mail if you have not already
> seen it.
> 
> For the configuration,  command output from *
> *
> 
> *postconf -n*
> 
> *postconf -Mf*
> 
> is a good starting point. Most people post it to the list, but if there
> are concerns you can post a link. 
> 
> It might also be helpful to see the full logging for a test message but
> without verbose option (you can anonymize the email address).
> 
> John
> 
> 

hi, here i pasted the requested information

$ postconf -n
http://www.icu-project.org/

$ postconf -Mf
http://termbin.com/1j71


Full log of test message (sendmail -bv address) run with local -v (set
in master.conf): http://termbin.com/ram9

full log of test message without -v:
Dez 23 12:30:51 dukun postfix/local[4759]: warning: error looking up
passwd info for AA: Invalid argument
Dez 23 12:30:51 dukun postfix/local[4759]: B5AE47A04BD:
to=, relay=local, delay=0.06, delays=0.04/0/0/0.02,
dsn=4.0.0, status=undeliverable (user lookup error)

i hope i got everything.
georg

Re: Postfix delivery problem

[G. Schlisio]

> 
> Georg
> 
> probably the best thing is to compare your previous configuration to the
> new one and see what changed.
> 
> For help with your current configuration, you should post it.
> 
> John

hi john,

thank you for your suggestion. as i tried to indicate with "no changes
in mail config" there was actually no change whatsoever. a diff to the
backuped config confirms this.
whats the right way to post ones config semi-public (not stored forever
in the web)? will a paste of 'postconf -n' to a paste server do?

thank you for your help
georg

Postfix delivery problem

[G. Schlisio]

Dear list,

We have a mail server with postfix and dovecot on Archlinux where we
have mail
addresses with local unix accounts (authenticated by pam) and without
unix accounts (dovecot passwd-file authentication). The problem only
affects those non-unix account mail addresses. (There are also
completely virtual email addresses with different domains, also managed
by dovecot, but still working fine, for simplicity ignored here; sorry
the config is really complicated).

All non-unix-account addresses are listed in a postfix table,
configured in main.cf by:
mailbox_transport_maps = hash:/etc/postfix/mailbox_transport_maps

looking like this:
user1  dovecot
user2  dovecot

All this was working fine, before yesterdays (rather big)
system-upgrade.
Now we get the following error in the mail logs:

: delivery via local: user lookup error

postfix/local in verbose mode complains:

postfix/local[27333]: deliver_switch[2]: local user recip u...@dukun.de
exten  deliver u...@dukun.de exp_from
dukun postfix/local[27333]: deliver_alias[3]: local user recip
u...@dukun.de exten  deliver u...@dukun.de exp_from
dukun postfix/local[27333]: deliver_alias:
hash:/etc/aliases(0,lock|no_regsub|no_proxy|no_unauth|fold_fix|utf8_request):
user not found
dukun postfix/local[27333]: dict_pcre_lookup:
/etc/postfix/aliases_regex: user
dukun postfix/local[27333]: deliver_alias:
pcre:/etc/postfix/aliases_regex(0,lock|no_regsub|no_proxy|no_unauth|fold_fix|utf8_request):
user not found
Dez 23 01:56:03 dukun postfix/local[27333]: deliver_dotforward[3]: local
user recip u...@dukun.de exten  deliver u...@dukun.de exp_from
postfix/local[27333]: warning: error looking up passwd info for user:
Invalid argument

It seems like postfix/local is ignoring the mailbox_transport_maps
option and trying to deliver itself instead of passing to dovecot, thus
finding no entry in the system passwd.
After full upgrade config files were merged (no changes in mail config)
and a reboot was done. The list of upgraded packages is shown at
http://termbin.com/k5ql . As downgrading postfix, dovecot and icu
(linking) did not resolve this issue, we are very confused.

As this is critical infrastructure for some people, any help is warmly
appreciated.

regards
georg