Re: Outgoing DANE not working
On Mon, May 18, 2020 at 10:38:14PM -0400, Viktor Dukhovni wrote: > On Mon, May 18, 2020 at 09:37:36PM -0400, Rich Felker wrote: > > > > Mostly dig, unbound-host, ... Most of the platform C libraries support > > > DO=1, which obviates the need for AD=1, so they don't do that, but it is > > > nevertheless safe. AD=1 is much cheaper than DO=1, because you get back > > > just the AD bit without the excess RRSIG baggage, which is not needed > > > when you're not doing your own validation. > > > > I have a proposed solution expected to go upstream in this release > > cycle: res_* set AD bit unconditionally in outgoing queries, but the > > [backend for the] netdb.h functions clears it after calling > > __res_mkquery. > > > > This ensures that even if there are some broken nameservers/networks > > still that can't handle AD in queries, the standard, widely-used, > > high-level lookup APIs will still work, and at worst res_query breaks. > > > > Note that the netdb.h functions have no use for the AD bit and no way > > to pass it back to the caller, so there is no reduction in > > functionality by having them clear it. > > This sounds reasonable. Will there be a way for Postfix to detect the > new library version, so that we don't disable DANE for musl-libc > versions that do set the AD bit? I'm really disappointed with the detection, which made things much worse by producing postfix builds that won't do DANE even after libc.so is upgraded. It should have just worked after upgrade. The test is also somewhat broken in that it gets the wrong result if /bin/sh is static-linked, or if you have postfix built against musl on a system where /bin/sh is glibc-based, etc. and I don't even know what happens if you're cross-compiling or if that's even supported at all. There's not really a "test for versions that do set" by version; I would expect once the patch is upstream and tested, distros like Alpine would just apply it to their existing musl package rather than waiting to upgrade to get it. The only real test is a runtime one, calling res_mkquery and observing that it's set. BTW I saw in git master you added an additional musl test of the same form for the res_n* APIs. A simpler way to detect them is just with __RES macro in resolv.h, which indicates the supported API version. AIUI it's provided by all known implementations, though I haven't actually checked that. Rich
Re: easiest way to reject/process emails based on Return Path
On Mon, 2020-05-18 at 13:50 -0400, Bill Cole wrote: > In 30 years of working with Internet email, I have never seen any > fully > automated mechanism for making its delivery reliable in general, > non-contracted cases. ... > There is no virtual replacement for a physical process server. Maybe > someday that will mean robots of some sort (e.g. drones) but before I embark on an interesting conversation, can somebody confirm that I am not veering off-topic? I came here for a technical solution. Jerry gave an elegant one, although I am not ethically comfortable with it. The problem of Internet email is the problem of any federated standard. Embrace, Extend, Extinguish. Internet email is being replaced by text messaging, and I dare betting that fax will survive Internet email, because fax has a niche that Internet email has failed to create for itself. Fax niche is the communication with adverse interest. A minimum common denominator, that enable the less powerful of the parties to stay in the game. Internet email could have been even better. Could have... I am not expecting process serving standards (though I wish mechanical process serving could be replaced by something electronic). Just the same reliability of fax transmission (if the message gets lost after the 250, the fax operator is liable) would be good enough to give Internet email more purpose than the delivery of spam. -- Yuval Levy, JD, MBA, CFA Ontario-licensed lawyer https :// moneylaw.ca Tel: 1.844.234.5389 Fax: 1.888.900.5709
Re: Outgoing DANE not working
On Mon, May 18, 2020 at 09:37:36PM -0400, Rich Felker wrote: > > Mostly dig, unbound-host, ... Most of the platform C libraries support > > DO=1, which obviates the need for AD=1, so they don't do that, but it is > > nevertheless safe. AD=1 is much cheaper than DO=1, because you get back > > just the AD bit without the excess RRSIG baggage, which is not needed > > when you're not doing your own validation. > > I have a proposed solution expected to go upstream in this release > cycle: res_* set AD bit unconditionally in outgoing queries, but the > [backend for the] netdb.h functions clears it after calling > __res_mkquery. > > This ensures that even if there are some broken nameservers/networks > still that can't handle AD in queries, the standard, widely-used, > high-level lookup APIs will still work, and at worst res_query breaks. > > Note that the netdb.h functions have no use for the AD bit and no way > to pass it back to the caller, so there is no reduction in > functionality by having them clear it. This sounds reasonable. Will there be a way for Postfix to detect the new library version, so that we don't disable DANE for musl-libc versions that do set the AD bit? -- Viktor.
Re: Outgoing DANE not working
On Tue, Apr 14, 2020 at 05:59:51PM -0400, Viktor Dukhovni wrote: > > > That RFC was published in 2013. That's long enough ago. > > > > We support environments that haven't been touched since 2009 or so, > > and to a lesser/minimal-support extent ones that haven't been touched > > since around 2004. Your idea of environments Postfix might be running > > on musl in is very different from the concept of environments that > > arbitrary applications binaries linked to musl might be running in. > > Nevertheless, the AD bit is on by default in dig and similar tools, with > no reports of any issues in a long time. Do you see dig fail where MUSL > libc lookups succeed? I'm asking around the DNS community for any > evidence of barriers to AD=1, so far nobody knows of any. I'll try to > find more compelling evidence, but basically tolerating AD=1 (either > ignoring or acting on it per the 2013 RFC) is *required* resolver > behaviour. > > > So if there's any chance of this breaking there almost certainly needs > > to be a way to turn it off that works even on static binaries. > > Whether and where to place such controls is your call. If novel > /etc/resolv.conf options are not a problem for statically linked > binaries using something other than musl-libc, then you could > have: > > options noad ... > > but if that is incompatible with other stub resolver libraries on the > same machine, you may need a private musl-specific configuration file. > > My money is on this being unnecessary. I'll let know what I find > from dns-operations, and if possible perhaps a RIPE ATLAS probe, > assuming they support enabling AD=1. > > > > In that case, set the AD bit unconditionally, or provide a documented > > > mechanism to do so via a suitable configuration file. > > > > Putting it in resolv.conf on an options line is probably the best. The > > main remaining question is just which default to use, and where to > > apply it (at res_mkquery or at res_send). > > Your call. > > > > Find me a resolver that fails when the AD bit is set. Stub resolvers > > > that always set it have been around for some time now. > > > > Do you know if the usual Windows, Android, iOS, etc. ones always set > > it? If so it's almost surely safe to do so and this might not even > > need to be an option (which would really be my favorite coarse of > > action -- making it unconditional so there's no new configuration to > > invent). > > Mostly dig, unbound-host, ... Most of the platform C libraries support > DO=1, which obviates the need for AD=1, so they don't do that, but it is > nevertheless safe. AD=1 is much cheaper than DO=1, because you get back > just the AD bit without the excess RRSIG baggage, which is not needed > when you're not doing your own validation. I have a proposed solution expected to go upstream in this release cycle: res_* set AD bit unconditionally in outgoing queries, but the [backend for the] netdb.h functions clears it after calling __res_mkquery. This ensures that even if there are some broken nameservers/networks still that can't handle AD in queries, the standard, widely-used, high-level lookup APIs will still work, and at worst res_query breaks. Note that the netdb.h functions have no use for the AD bit and no way to pass it back to the caller, so there is no reduction in functionality by having them clear it. Rich
Re: Undefined Parameters
I solved it. The white space in front of the arguments had been removed so it was reading them as an instruction that it could not understand. Replacing the white space solved the issue thank you. Geoff +44 20 7100 1092 +44 7770 58 48 38 +33 5 46 97 13 89 +33 6 22 93 00 53 > On 17 May 2020, at 22:56, Wietse Venema wrote: > > Geoff Jankowski: >> May 17 23:15:45 xerxes ifup[5524]: postconf: warning: >> /etc/postfix/master.cf: undefined parameter: mua_sender_restrictions > > Something (Postfix master.cf or main.cf) is using $mua_sender_restrictions, > but that parameter is not defined in main.cf or master.cf. > > In master.cf: > $ postconf -P | grep mua_sender_restrictions > > In main.cf: > $ postconf -n | grep mua_sender_restrictions > > Wietse
Re: easiest way to reject/process emails based on Return Path
On Mon, 18 May 2020 18:20:36 +0200, Jaroslaw Rafa stated: >Dnia 18.05.2020 o godz. 11:50:53 yuv pisze: >> discarded the message. It is one of the main reasons why we lawyers >> continue to use fax transmission: the protocol is reliable, my fax >> device receives the equivalent of a 250, I can rely on the fact that >> something has been delivered. Not silently discarded. > >In what area of the world people are still using faxes? >I haven't heard abut anybody using fax (even a lawyer) for years. FAXs are used my municipalities all the time. -- Jerry
Re: easiest way to reject/process emails based on Return Path
On 18 May 2020, at 11:50, yuv wrote: To claim successful delivery and silently discard a message is a lie. A 250 reply to end-of-data is not a claim of final delivery. Even if there's following text that seems to assert that the message is delivered, it has always been true that one cannot rely on that delivery being to a final destination which is readily accessible to the intended recipient. The legal term is *misrepresentation* It is not misrepresentation. The SMTP protocol definitions have NEVER required the 250 reply to end-of-data to indicate actual (much less final) delivery and has ALWAYS explicitly cautioned against reliance in any way on the optional text part of any server reply. and I am eagerly waiting for the client coming through my door who has been damaged by an email service operator that replied with a 250 and then silently discarded the message. I am not a lawyer in any sense and so cannot give any legal advice worth taking, however I have been peripherally involved in civil suits under US law which have touched on this issue in their pre-trial phases and I believe that you would be wise to research relevant precedents before taking on that hypothetical client, and especially to not take on such a client on a contingent fee basis. I can't do that research for you or even point at any case where non-delivery of Internet email has been an issue at trial or in appeals. If you practice in the US, I know that 47 U.S. Code § 230 can be relevant but may or may not be in any particular case. It is one of the main reasons why we lawyers continue to use fax transmission: the protocol is reliable, my fax device receives the equivalent of a 250, I can rely on the fact that something has been delivered. Not silently discarded. A wise practice. On the other hand, the fax acknowledgement does not normally guarantee that the fax machine does not feed directly into a shredder or incinerator, or simply that there wasn't a fatal paper jam or ink mishap in the fax machine's printer. However, the fact that fax acknowledgements are generally considered reliable is largely a consequence of laws like the US TCPA (and the abuses prior to regulation.) In 30 years of working with Internet email, I have never seen any fully automated mechanism for making its delivery reliable in general, non-contracted cases. Proposals for that have always failed in some fashion due to the fact that there's no universal standard mechanism for how email is handled after it leaves the realm of SMTP. Spammers (and the slightly broader population of people who fear being seen as spammers) have sought mechanisms to automatically verify addresses for decades and have only succeeded in making it increasingly true that the only way to confirm any email address as being delivered to a human is to send it email and get a clearly human-written reply. Even that verification is valid for just that one message. There is no virtual replacement for a physical process server. Maybe someday that will mean robots of some sort (e.g. drones) but -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not For Hire (currently)
Re: easiest way to reject/process emails based on Return Path
Dnia 18.05.2020 o godz. 11:50:53 yuv pisze: > Thanks for the suggestion, Gerald. I was hoping for something more ... > *honest*. To claim successful delivery and silently discard a message > is a lie. The legal term is *misrepresentation* and I am eagerly > waiting for the client coming through my door who has been damaged by > an email service operator that replied with a 250 and then silently > discarded the message. For a mail service operator it would actually be unacceptable. But for *end recipient* it's a different story. It's your own (ie. your company's) server, so you represent an *end recipient*, not a mail service operator, and any action you perform, you perform as (or on behalf of) the end recipient. No recipient has an obligation to read all mail that's coming to them (well, maybe lawyers view it differently? ;)). Delivered doesn't mean read. Accepting a message and silently discarding it is no different from deleting a message without even opening it - only the former is automated, but this automation is authorized by you - it's you who, as the end recipient, set the rule to discard messages. You are absolutely allowed to do it. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub."
Re: easiest way to reject/process emails based on Return Path
Dnia 18.05.2020 o godz. 11:50:53 yuv pisze: > discarded the message. It is one of the main reasons why we lawyers > continue to use fax transmission: the protocol is reliable, my fax > device receives the equivalent of a 250, I can rely on the fact that > something has been delivered. Not silently discarded. In what area of the world people are still using faxes? I haven't heard abut anybody using fax (even a lawyer) for years. -- Regards, Jaroslaw Rafa r...@rafa.eu.org -- "In a million years, when kids go to school, they're gonna know: once there was a Hushpuppy, and she lived with her daddy in the Bathtub."
Re: easiest way to reject/process emails based on Return Path
On Fri, 2020-05-08 at 09:51 +0200, Gerald Galster wrote: > > > Below is the PCRE that I came up with to catch the offending > > > messages, > > > without blocking other correspondence (the contacts and their > > > organizations are likely to use Google's SMTP for their regular > > > emails): > > > > > > /^Return-Path:(.+)(calendar- > > > server.bounces.google.com)(.*)/ REJECT No > > > Google Calendar Spam Here > > > > If you reject mail from Google, Google will stop sending you mail. > > ALL mail. Can you afford that? > > You could use DISCARD instead of REJECT. > > #DISCARD optional text... > # Claim successful delivery and silently discard the > # message. Log the optional text if specified, oth- > # erwise log a generic message. > Thanks for the suggestion, Gerald. I was hoping for something more ... *honest*. To claim successful delivery and silently discard a message is a lie. The legal term is *misrepresentation* and I am eagerly waiting for the client coming through my door who has been damaged by an email service operator that replied with a 250 and then silently discarded the message. It is one of the main reasons why we lawyers continue to use fax transmission: the protocol is reliable, my fax device receives the equivalent of a 250, I can rely on the fact that something has been delivered. Not silently discarded. As for the other comments elicited by my post: is there any evidence that Google stops sending ALL mails on some very specific rejections? or is this just FUD? After all, Google is used by millions of senders, and some of them are most obvious spammer. Does anyone expect an email server to accept an email containing a request to send money by Western Union to some exotic country in exchange for the prospect of receiving an inheritance from an obscure prince or despot of said country? Thanks, Yuv
Re: Connection reuse and tlsproxy
Le 27/09/2019 à 17:01, Emmanuel Fusté a écrit : Hello, I started to deploy TLS connection reuse on some non trivial outboud gateway setups. First I was hit by an non obvious configuration behavior: On my gateway I have: smtpd_tls_security_level=none smtp_tls_security_level=dane If I switch to TLS session reuse with smtp_tls_connection_reuse=yes I get: tlsproxy: warning: TLS service is requested, but disabled with tlsproxy_tls_security_level or tlsproxy_use_tls smtp: warning: private/tlsproxy service role "client" is not available. By default tlsproxy_tls_security_level=$smtpd_tls_security_level I overwrite it with tlsproxy_tls_security_level=may and it worked. But as tlsproxy_client_level = $smtp_tls_security_level (=dane) why I need to enable tlsproxy "server" part to get the "client" part working ? Overlook/Bug ? Yeahh, fixed in 3.5.2/3.4.12 Thank you ! Emmanuel.
Re: Undefined Parameters
On 17.05.20 22:51, Geoff Jankowski wrote: I am using postfix 3.4.8 on Debian 10 (hostname xerxes) and am trying to set up my IPv6 interface on eth0. The last instruction in the guide is to run: service networking restart But it fails to bring up the interface (which is working on IPv4). It tries to run: ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE) And the critical errors given are: May 17 23:15:45 xerxes ifup[5524]: ifup: failed to bring up eth0 May 17 23:15:45 xerxes ifup[5524]: postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_sender_restrictions May 17 23:15:45 xerxes ifup[5524]: postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_client_restrictions May 17 23:15:45 xerxes ifup[5524]: postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_helo_restrictions Reading /etc/network/Ifup it refers to using postconf which for Debian 10 is in /etc/sbin/ but it cannot be read as it appears to be a binary file(?). postconf is the program that complains, you don't have to see its content. It's complaining about content of /etc/postfix/master.cf, not /usr/sbin/postconf When I investigate my master.cf file these three elements mua_sender_restrictions, mua_client_restrictions and mua_helo_restrictions Are commented out so no definition is given and I assume that postconf is looking for them. Reading the postfix.org site I chose recommended settings for each of these items, uncommented the lines and inserted them. To be safe, I rebooted. They are default in master.cf but commented out for submission ans smtps services: # -o smtpd_client_restrictions=$mua_client_restrictions # -o smtpd_helo_restrictions=$mua_helo_restrictions # -o smtpd_sender_restrictions=$mua_sender_restrictions I usually leave them commented out. Immediately after reboot, I ran a status request and the output was as follows: May 17 23:15:45 xerxes ifup[5524]: ifup: failed to bring up eth0 May 17 23:15:45 xerxes ifup[5524]: postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_sender_restrictions May 17 23:15:45 xerxes ifup[5524]: postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_client_restrictions May 17 23:15:45 xerxes ifup[5524]: postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_helo_restrictions May 17 23:15:45 xerxes ifup[5524]: postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_sender_restrictions May 17 23:15:45 xerxes ifup[5524]: postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_client_restrictions May 17 23:15:45 xerxes ifup[5524]: postconf: warning: /etc/postfix/master.cf: undefined parameter: mua_helo_restrictions How and where did you define them? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. 10 GOTO 10 : REM (C) Bill Gates 1998, All Rights Reserved!
Re: No delivery attempt
Postfix does not remove mail from the queue without logging it. Without logs there will be no support. Seriously. Systemd is great for losing logs while you're doing bulk mail. If your system has systemd, consider using Postfix's maillog_file feature instead. Again, Without logs there will be no support. Wietse
Postfix stable release 3.5.2 and legacy releases 3.4.12, 3.2.10, 3.2.15
[An on-line version of this announcement will be available at http://www.postfix.org/announcements/postfix-3.5.2.html] Postfix versions 3.5.2, 3.4.12, 3.2.10, 3.2.15: * A TLS error for a database client caused a false 'lost connection' error for an SMTP over TLS session in the same Postfix process. Reported by Alexander Vasarab, diagnosed by Viktor Dukhovni. This bug was introduced with Postfix 2.2. * The same bug existed in the tlsproxy(8) daemon, where a TLS error for one TLS session could cause a false 'lost connection' error for a concurrent TLS session in the same process. This bug was introduced with Postfix 2.8. * The Postfix build now disables DANE support on Linux systems with libc-musl such as Alpine, because libc-musl provides no indication whether DNS responses are authentic. This broke DANE support without a clear explanation. * Due to implementation changes in the ICU library, some Postfix daemons reported file access errrors (U_FILE_ACCESS_ERROR) after chroot(). This was fixed by initializing the ICU library before making the chroot() call. * Minor code changes to silence a compiler that special-cases string literals. Postfix 3.5.2, 3.4.12: * Segfault (null pointer) in the tlsproxy(8) client role when the server role was disabled. This typically happened on systems that do not receive mail, after configuring connection reuse for outbound SMTP over TLS. * The date portion of the maillog_file_rotate_suffix default value used the minute (%M) instead of the month (%m). Reported by Larry Stone. You can find the updated Postfix source code at the mirrors listed at http://www.postfix.org/. Wietse
Re: TLS problem: no shared cipher?
On 2020-05-17 12:07:29 -0600, @lbutlr wrote:
> > postfix/smtpd[17880]: connect from ...[...]
> > postfix/smtpd[17880]: SSL_accept error from ...[...]: -1
> > postfix/smtpd[17880]: warning: TLS library problem: error:1417A0C1:SSL
> > routines:tls_post_process_client_hello:no shared
> > cipher:ssl/statem/statem_srvr.c:2282:
> > postfix/smtpd[17880]: lost connection after STARTTLS from ...[...]
> > postfix/smtpd[17880]: disconnect from ...[...] ehlo=1 starttls=0/1
> > commands=1/2
>
> Are you requiring that mailservers connect only with TLS?
No.
> I suspect you are, and that you new upgrade has removed support for the EOLed
> TLSv1.0 and TLSv1.1.
No, TLSv1.0 and v1.1 are still active; the problem was the
non-RSA-certificate.
> Normally, a failed negotiation of TLS on smtpd will result in the connection
> continuing with no encryption.
Unfortunately, not in this case.
It looks like if the other mailserver does not know the
certificate-type, it does not retry without encryption.
> You should probably have:
> smtpd_tls_security_level = may
As I wrote before: I have.
> > did not help; the only way to receive
> > the mails was disabling TLS completely ("smtpd_tls_security_level = none").
> > But I would like to enable TLS again.
>
> Then your setting should almost certainly be ‘may’ if you want to receive
> mail from this server.
I have tested this, and that does not help here.
> > (Change in Postfix default configuration? Bad certificate? Bad TLS library?
> > Bad TLS on other mailserver?)
>
> Spammer scum, most likely.
No, definitely not.
The problem were incompatible certificate-types (ec384, which were not
supported by the other mailserver). Switching to RSA certificates, and
everything worked again.
Roland
