Re: Sieve vacation and smtp_sasl_password_maps
In my system I have 10 users. Each user has his own upstream account on the ISP. I use postfix + dovecot + fetchmail as a local mail server, but the real sending is done by my ISP. I only forward local mails and the rest goes out by the ISP. When I authenticate the SMTP connection, my ISP will only allow that user to send the mail. Like, if I use user1 credentials as the default, then user2 won't be able to send mails. They will bounce back. Isn't this is the reason smtp_sender_dependent_authentication is created for? Thanks for your help. Gianni On 23 Nov 2019, at 10:13, Gianni Angelozzi wrote: Yes, I need smtp_sender_dependent_authentication because the upstream ISP will only accept incoming mails from the authenticated user. That doesn’t imply a need for smtp_sender_dependent_authentication. That is needed, AIUI, when you have multiple senders on your system who all need separate authentication. Enable sender-dependent authentication in the Postfix SMTP client; this is available only with SASL authentication, and disables SMTP connection caching to ensure that **mail from different senders** will use the appropriate credentials. (Emphasis mine)
Re: Reject Chinese mail
> I don't block based on country but I do add some weighting in Spamassassin > for [...] Absolutely i agree with you Dominic, thanks^^^ Sincerely, -- ^고맙습니다 _地平天成_ 감사합니다_^))//
Re: Reject Chinese mail
Hello Jeffrey, > I don’t get the logic of this statement. [...] There are my several cousin brothers, friends over the world. So i can't block any regions. The word money is not money in the statement. Sincerely, -- ^고맙습니다 _地平天成_ 감사합니다_^))//
Re: Sieve vacation and smtp_sasl_password_maps
> On 24 Nov 2019, at 03:42, Gianni Angelozzi wrote: > > In my system I have 10 users. Each user has his own upstream account on the > ISP. If you mentioned that before, I missed it. > When I authenticate the SMTP connection, my ISP will only allow that user to > send the mail. Like, if I use user1 credentials as the default, then user2 > won't be able to send mails. They will bounce back. In that case you do need smtp_sender_dependent_authentication (though I would go with a different provider or not run my mail server on a home connection). -- 'It's vital to remember who you really are. It's very important. It isn't a good idea to rely on other people or things to do it for you, you see. They always get it wrong.' —Sourcery
Re: Validation DMARC
> Or in short: DMARC intentionally breaks every mailinglist and every > mail-forwarding. So, if a mail-provider uses a strict DMARC-policy, > it effectively says: "Our mail-addresses may not be used for > mailinglists." this message (i am replying to) from you on this mailing list is not broken
Re: Validation DMARC
On 11/24/19 3:12 PM, Chris Wedgwood wrote: >> Or in short: DMARC intentionally breaks every mailinglist and every >> mail-forwarding. So, if a mail-provider uses a strict DMARC-policy, >> it effectively says: "Our mail-addresses may not be used for >> mailinglists." > this message (i am replying to) from you on this mailing list is not > broken > This list is somewhat unusual in that it doesn't include a footer with list instructions, nor does it add a subject identifier to quickly identify that the message comes from this list. My guess is that two things are likely true: 1) This list is not run in a locality that requires obvious unsubscription instructions, or that it has been decided that the List-Unsubscribe header is good enough to meet that requirement 2) It is presumed that subscribers to this list are competent enough to not need to be reminded about operating instructions. (This list's subject matter is fairly technical, so not apt to draw less technically adept subscribers). -- Richard Damon
Re: presenting TLS Client Certificates without breaking TLS to mixed MSA/MX
Am Freitag, 22. November 2019, 23:08:39 CET schrieb Ralph Seichter: > * Lars Kollstedt: > > is there a clean way to optionally present a client certificate to a > > Postfix MX [...] > > I hope I don't misinterpret your question here. [...] > However, I don't see you using relay_clientcerts=/path/to/clientcerts > anywhere. That would be required on the SMTP server side to actually > look up certificate fingerprints. Hi Ralph, at first thank you for the reply. But I'm not talking about doing relay control via client certificates. This is just a setup I know and I don't want to break, if someone does it on the same host and port as his MX. We've someone running smtpd_tls_received_header=yes smtpd_tls_ask_ccert = yes smtpd_tls_CApath=/etc/ssl/certs on his Postfix MX servers in our nearer environment, but I don't want to maintain a list of all his domains to present the client certificate there. But I understand the wish to also cryptographically verify this direction. So I would like to make his servers logging the verification of the client certificate "I've crypographically sure got the mail from that host." At the moment it's a single MX server name on the other end but a bunch of domains. And since the transport map is working on domain names prior of the MX lookup (at least as far as I know) this is not an option. Something mapping the transport method the after MX lookup was done would solve this, for my current usecase. With the single server configured this way on the other end. But it's of course not worth breaking the mail delivery or TLS to other mail recipients where relay control is done this way on port 25 of the MX server, in a way that causes problems if an unexpected client certificate is presented. So the question was if there is a clean way, to configure a client certficate that is tried to present, and left away in case of failure. Unfortunately this will need a second connection, when tried without the other side to signal what kind of verification is done. And it's not possible to determine the reason of failure, that's the reason of my worries about greylisting. The more I'm thinking about this seems to be more a protocol extension for future but anything that can be implemented by configuration - without breaking anything, yet. Kind regards, Lars -- Lars Kollstedt Telefon: +49 6151 16-71027 E-Mail: l...@man-da.de man-da.de GmbH Dolivostraße 11 64293 Darmstadt Sitz der Gesellschaft: Darmstadt Amtsgericht Darmstadt, HRB 9484 Geschäftsführer: Andreas Ebert
Pflogsummand nbzcat
Is there a simpler way to do this (since bzcat can’t cat a text file) 👹 # bzcat mail.log.* > /tmp/mail.combined && cat mail.log >> /tmp/mail.combined 👹 # pflogsumm /tmp/mail.combined --detail 15 -- I've got a sonic screwdriver! Yeah? I've got a chair! ... Chairs *are* useful.
Re: presenting TLS Client Certificates without breaking TLS to mixed MSA/MX
On Sun, Nov 24, 2019 at 09:45:20PM +0100, Lars Kollstedt wrote: > We've someone running > > smtpd_tls_received_header=yes > smtpd_tls_ask_ccert = yes > smtpd_tls_CApath=/etc/ssl/certs > > on his Postfix MX servers in our nearer environment, but I don't want > to maintain a list of all his domains to present the client > certificate there. > > But I understand the wish to also cryptographically verify this > direction. So I would like to make his servers logging the > verification of the client certificate "I've crypographically sure got > the mail from that host." > > At the moment it's a single MX server name on the other end but a > bunch of domains. And since the transport map is working on domain > names prior of the MX lookup (at least as far as I know) this is not > an option. Humouring the curiousity of that particular receiving system is not worth the complexity of attempting to keep track of the associated domains, or presenting client certs to all strangers who ask and then inventing a complex fallback scheme in case they fumble the resulting handshake. Your best bet is to simply not configure any client certs, you don't need them to get the mail delivered. Yes, Postfix could in principle have late binding of client certificates by MX hostname (a dual to SNI-based certificate selection on the server). It is not clear that there is sufficient merit in such a feature. -- Viktor.
Re: Validation DMARC
Why it doesn’t break From: header SPF? Just curious On Mon, Nov 25, 2019, at 4:12 AM, Chris Wedgwood wrote: > > Or in short: DMARC intentionally breaks every mailinglist and every > > mail-forwarding. So, if a mail-provider uses a strict DMARC-policy, > > it effectively says: "Our mail-addresses may not be used for > > mailinglists." > > this message (i am replying to) from you on this mailing list is not > broken >
Re: Validation DMARC
* Wesley Peng: > Why it doesn’t break From: header SPF? Just curious See https://tools.ietf.org/html/rfc7208, in particular the "MAIL FROM Definition" section. -Ralph
Re: Validation DMARC
On 11/24/19 6:21 PM, Wesley Peng wrote: > Why it doesn’t break From: header SPF? Just curious > > On Mon, Nov 25, 2019, at 4:12 AM, Chris Wedgwood wrote: >> > Or in short: DMARC intentionally breaks every mailinglist and every >> > mail-forwarding. So, if a mail-provider uses a strict DMARC-policy, >> > it effectively says: "Our mail-addresses may not be used for >> > mailinglists." >> >> this message (i am replying to) from you on this mailing list is not >> broken >> It DOES break DMARC/SPF, as the IP address the message comes from doesn't match the From of the message, but with DMARC if EITHER SPF or DKIM pass, the message is to be considered to pass. A Domain with strict DMARC, and which doesn't DKIM sign messages, will fail with any form of remailer, so would fail for this application. -- Richard Damon
Re: presenting TLS Client Certificates without breaking TLS to mixed MSA/MX
Hi Viktor, at first thank you for your two answers. I decided to keep my reactions to them in order but in all in this answer. ;-) On Friday, 22. November 2019, 23:29:46 CET Viktor Dukhovni wrote: > Have you recently seen MX hosts that solicit client certs and then abort > the TLS handshake when these don't verify? Not, yet. But stumbling into this when someone is running his MSA and MX on the same host and port is something I want to avoid. > The Postfix documentation > speculatively warns against promiscuous use of client certs: > > http://www.postfix.org/postconf.5.html#smtp_tls_cert_file > > Do not configure client certificates unless you must present client > TLS certificates to one or more servers. Client certificates are not > usually needed, and can cause problems in configurations that work > well without them. > but the ecosystem may have improved since those words of caution were > written. I know this warning. And I understand where it cames from. And what I did was an attempt to work around this. See this mailinglist post more as a test balloon for this. But there was not a bunch of people answering this warning is deprecated, and I don't want to try. ;-) [...] > You have failed to read the documentation of "fallback_transport". > > http://www.postfix.org/postconf.5.html#fallback_transport > > Optional message delivery transport that the local(8) delivery agent > should use for names that are not found in the aliases(5) or UNIX > password database. > > It is NOT used on SMTP delivery (temporary) failure. I've also read this description. The name duality of "default_transport" and "fallback_transport" and some experiences with the fallback_transport that are long ago, lead me to nevertheless try this. But obviously it's only a name duality nowadays. The two directives seem to have nothing to do with each other (anymore?). > > > But postfix isn't even trying with the fallback transport in this case. > As expected. As documented, see above. ;-) But I don't want to discuss about that. ;-) Both answers my question, that far. ;-) :-) > There's no need to attempt to present your client certificate to random > strangers, even if they're bold enough to ask whether you're one of > their relations. We're in relation to the interesting target. But I still don't want to maintain a list of all possible mail destination domains. Mail delivery is controlled via MX records for good reasons there and wildcards don't help. > > Postfix does not presently have support for a sort of inverse-SNI, > where a client certificate chain is selected via the tls policy table, > without a dedicated custom transport. That's an answer. I don't need different certs but a way to turn this off and on, after the MX lookup was done. > It is not clear this is needed. Needed is a big word for this. Especially since this would only partially fix the usecase. I was just evaluating the possibilities. And my interest was if I was overlooking some extensions, solving this. On Sunday, 24. November 2019, 22:55:51 CET Viktor Dukhovni wrote: [...] > Yes, Postfix could in principle have late binding of client certificates > by MX hostname (a dual to SNI-based certificate selection on the server). > It is not clear that there is sufficient merit in such a feature. [...] You were to fast with your answer. ;-) I was still typing on this one. I left my previous answers to you in above. The more I think about all this: What I really would like to have is the recipient server to signal something like an TLSMTAVERIFICATION ESMTP-keyword back to me and activating some client certificates configured especially for that on my side. And they're verified on the recipient server in different ways: 1. If there are CAs for Relay-Control and special CAs they are verified first. 2. if SMTP helo-Hostname and PTR-Hostname have DANE-TSA for _25._tcp. records they must (both) match, if a certificate is presented that does'nt match (1.). Otherwise mail is deferred. 3. There might be a bunch of manual filtering and signaling possibilities on the recipient server based on the trust, the CAs and the fingerprints. Not all of them are without side effects in all cases. 4. Any other seen client certificate is verified against the configured system certificates and the result is logged to the header if "smtpd_tls_received_header=yes" is set. 5. Since DANE is elder something else must be used to enforce the use of TLSMTAVERIFICATION if wanted. But that's only a dream till now. And there are probably more urgend things to do within the smtp transport. ;-) For now I'll take this as a answer there is still no good way to do this, yet. I'll wait which way all this will take in the next years. [...] > Your best bet is to simply not configure any client certs, you don't > need them to get the mail delivered. [...] With the curr
Re: Validation DMARC
That's great explation. Thanks Richard. On Mon, Nov 25, 2019, at 7:33 AM, Richard Damon wrote: > On 11/24/19 6:21 PM, Wesley Peng wrote: > > Why it doesn’t break From: header SPF? Just curious > > > > On Mon, Nov 25, 2019, at 4:12 AM, Chris Wedgwood wrote: > >> > Or in short: DMARC intentionally breaks every mailinglist and every > >> > mail-forwarding. So, if a mail-provider uses a strict DMARC-policy, > >> > it effectively says: "Our mail-addresses may not be used for > >> > mailinglists." > >> > >> this message (i am replying to) from you on this mailing list is not > >> broken > >> > It DOES break DMARC/SPF, as the IP address the message comes from > doesn't match the From of the message, but with DMARC if EITHER SPF or > DKIM pass, the message is to be considered to pass. > > A Domain with strict DMARC, and which doesn't DKIM sign messages, will > fail with any form of remailer, so would fail for this application. > > -- > Richard Damon > >
