** Description changed:
+ [Impact]
+
+ Users cannot send emails using dane-only policy in Focal.
+
+ In this SRU we are proposing a microrelease update from version 3.4.10
+ to 3.4.11 since the changes are minimal (and also seems there is an
+ authorization from the Tech Board to do that). Here
Good to hear that Jan. I might have messed up my local setup. I'll
proceed with the SRU process to make this fix land in Focal.
** Changed in: postfix (Ubuntu)
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Hi Lucas,
yes your ppa version seems to work.
I can also send emails again with the dane-only policy.
Details:
The warning still exists, but posttls-finger gets a valid RR record:
root@www:~# posttls-finger -t30 -T180 -c -L verbose,summary bueren.space
posttls-finger: initializing the
You can foolproof this with your settings by writing to my test mail
account and setting this domain to dane-only:
"I created one test account you may use to send some local mail to:
ubuntu-bug@bueren.space"
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
@Nick and @Jan: could you please try postfix 3.4.11 available in the PPA
I mentioned above and give us some feedback? I'd like to confirm that
before asking for help on postfix-users mailing list.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
** Changed in: postfix (Ubuntu)
Status: Fix Released => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1868955
Title:
after upgrade to 20.04: posttls cannot connect to private/tlsmgr
In that case, someone with the new libc and postfix 3.4.11/3.5.2 or later
should write to the postfix-users list and ask for help. My recollection is
that the upstream developers did not have access to a system with the new libc
and were dependent on third party testing, so something may have
That was my initial thought. So I am not sure if just a postfix update
to version 3.4.11 (or 3.5.2 in Groovy) fixes the mentioned issue.
FWIW, I have a PPA here with the version 3.4.11 built in Focal and the
behavior is the same as version 3.5.2 in Groovy:
On Monday, June 8, 2020 4:59:30 PM EDT you wrote:
> postfix (3.5.2-1+b1) sid; urgency=low, binary-only=yes
> .
>* Binary-only non-maintainer upload for amd64; no source changes.
>* Rebuild against libicu67
> .
> -- all / amd64 / i386 Build Daemon (x86-conova-01)
> Wed, 03 Jun 2020
After Scott's comment about updating postfix to 3.4.11 I checked the
changelog of this version and I noticed the only change from 3.4.10 is:
20200416
Workaround for broken builds after an incompatible change
in GCC 10. Files: makedefs, Makefile.in.
Workaround for broken
** Also affects: postfix (Ubuntu Focal)
Importance: Undecided
Status: New
** Changed in: postfix (Ubuntu Focal)
Status: New => Triaged
** Changed in: postfix (Ubuntu Focal)
Importance: Undecided => Medium
** Changed in: postfix (Ubuntu)
Status: Triaged => Fix Released
That change is included in postfix 3.4.11 which is, of course, just
after the one that's in 20.04. "Someone" (i.e. not me) should look into
an SRU to update postfix. It has an existing microversion release
authorization from the Tech Board, so it shouldn't be too hard, it just
takes someone
Thanks Nick for your excellent debugging work. I found two long threads
related to this issue in the postfix-users mailing list:
http://postfix.1071664.n5.nabble.com/Outgoing-DANE-not-working-
tt105397.html#none
http://postfix.1071664.n5.nabble.com/PATCH-Glibc-2-31-DNSSEC-and-
I (by accident) discovered that glibc has introduced a new resolver
option in resolv.h:
#define RES_TRUSTAD 0x0400 /* Request AD bit, keep it in
responses. */
I've done some testing with this, and it resolves the issue with the AD
flag not being returned.
So based on this I think this
Re-assigning to glibc then. I think that's a good demonstration this
isn't a postfix issue.
** Package changed: postfix (Ubuntu) => glibc (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I've created a C program (attached) which demonstrates the issue. It can
be compiled using the following command:
gcc dnsadtest.c -lresolv
This command generates an executable called "a.out".
If I run a.out on Ubuntu 18.04 (bionic) I get the following output:
length of answer = 251
id = 10740
Sorry for the delay in providing an update...
My theory about the systemd-resolved DNSSEC option proved incorrect.
So taking a step back, here is what I know about the problem that I am
observing (i.e. specific to my test set-up):
* posttls-finger makes three DNS queries: The first query is for
I still think Nick's clue is promising, let's see what the results of
his tests will be.
There could be more than one thing causing DANE not to work. If enabling
DNSSEC in systemd-resolved makes it work we'll try to figure out why it
doesn't work with unbound-resolvconf.
--
You received this
HI Nick,
nice idea, sounds reasonable, but ...
I am not using systemd.resolv and I can see the ad flag if I query unbound
locally.
I am simply guessing: Maybe tlsmgr really needs systemd?
Anyway here are my settings and snippets:
sudo systemctl disable systemd-resolved
sudo systemctl enable
Hi guys.
I've made some progress with narrowing down the cause of this problem.
It looks like the whole "private/tlsmgr" thing is a bit of a red
herring, and the actual problem seems to be that the DNS query that is
sent lacks the AD flag.
I've confirmed that RES_USE_DNSSEC is included in the
Hi Jan.
Thanks for sending me that blogpost. I found it a really good read! :-)
I tried downloading some open-source code one other time (can't actually
remember what it was), and got horribly confused, but maybe (like you) I
might feel inspired to have another crack at some stage...
Nick.
Hi Nick,
yep. My workaround was to change this to dane instead of dane-only.
It is a tiny bit disappointing that it is still broken because I prefer to use
ubuntu as a server system instead of debian.
Reading this discussion I guess the feature is working in debian but not in
ubuntu.
I have this issue also, but my set-up involves having my submission
server send all emails to an internal mail relay, which then sends to
the destination SMTP server. I'm using "dane-only" for the connection
from the submission server to the mail relay, meaning that it is used
for all external
** Changed in: postfix (Ubuntu)
Importance: Undecided => Medium
** Changed in: postfix (Ubuntu)
Status: Confirmed => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1868955
Title:
On Thursday, March 26, 2020 5:31:05 PM EDT you wrote:
> On 2020-03-26 3:54 p.m., Scott Kitterman wrote:
> > Does applying this change help:
> >
> > https://salsa.debian.org/postfix-team/postfix-dev/-/commit/
> > b8e0b846e34eeaaa2315ead2304824b21b01fe7a
>
> Does not help.
>
> Sion
OK. That's
On 2020-03-26 3:54 p.m., Scott Kitterman wrote:
> Does applying this change help:
>
> https://salsa.debian.org/postfix-team/postfix-dev/-/commit/
> b8e0b846e34eeaaa2315ead2304824b21b01fe7a
Does not help.
Sion
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
There are some differences between stable and what was in unstable that Ubuntu
synced.
Does applying this change help:
https://salsa.debian.org/postfix-team/postfix-dev/-/commit/
b8e0b846e34eeaaa2315ead2304824b21b01fe7a
Scott K
--
You received this bug notification because you are a member
On 2020-03-26 2:40 p.m., Scott Kitterman wrote:
> On Thursday, March 26, 2020 12:22:20 PM EDT you wrote:
>> Comparing strace between Ubuntu and Debian (lxc launch images:debian/10)
>> showed that Debian's version doesn't try to connect to the tlsmgr socket
>> for some reason.
>>
>> Ubuntu
On Thursday, March 26, 2020 12:22:20 PM EDT you wrote:
> Comparing strace between Ubuntu and Debian (lxc launch images:debian/10)
> showed that Debian's version doesn't try to connect to the tlsmgr socket
> for some reason.
>
> Ubuntu 3.4.10-1:
...
> Debian 3.4.8-0+10debu1:
...
If you use
Comparing strace between Ubuntu and Debian (lxc launch images:debian/10)
showed that Debian's version doesn't try to connect to the tlsmgr socket
for some reason.
Ubuntu 3.4.10-1:
# grep connect /tmp/strace | grep AF_UNIX
connect(3, {sa_family=AF_UNIX, sun_path="private/tlsmgr"}, 110) = -1
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: postfix (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1868955
Title:
Thanks for your replies.
@andreas:
Well, it was a bit hidden in my bug report but the real issue is that postfix
doesn't delivers mail to dane-only domains:
to=, relay=none, delay=2126, delays=2126/0.01/0/0,
dsn=4.7.5, status=deferred (non DNSSEC destination)
I created one test account you
I don't recall seeing this issue in Debian, so I don't have any particular
suggestions. Since the postfix is identical, I'd be inclined to look
elsewhere.
Scott K
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
stracing posttls-finger:
4543 connect(3, {sa_family=AF_UNIX, sun_path="private/tlsmgr"}, 110) =
-1 ENOENT (No such file or directory)
If you cd into /var/spool/postfix and then try again, it will find the
tlsmgr socket. Further I cannot test as it seems my ISP blocks outbound
25/tcp, but in any
stracing posttls-finger:
4543 connect(3, {sa_family=AF_UNIX, sun_path="private/tlsmgr"}, 110) =
-1 ENOENT (No such file or directory)
If you cd into /var/spool/postfix and then try again, it will find the
tlsmgr socket. Further I cannot test as it seems my ISP blocks outbound
25/tcp, but in any
Bare openssl as in:
$ openssl s_client -showcerts -starttls smtp -connect gmail-smtp-
in.l.google.com:25
works fine.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1868955
Title:
after upgrade to
Thanks Jan for this bug report. I can indeed reproduce the issue; using
LXD containers the easiest steps are the following:
1. Launch a clean Eoan container
2. `apt install postfix` with "Local only" config, accept all the defaults
3. Run: `posttls-finger -c gmail.com`. The TLS connection
37 matches
Mail list logo
