Re: reject mail if dns and rdns differ
Plain old greylisting can yield many false positives, but recent implementations of milter-greylist for example will not greylist messages that validates SPF. It helps *a lot*. The question is: does it only help "a lot", or is the result "zero false positives"? I personally don't believe SPF was a good idea, so for me it's not clear that it fully solves the problem mentioned by Jaroslaw Rafa. Gregory
Re: Question about DMARC
On 2019-11-22 04:21 GMT, Wesley Peng wrote: > The email I am using is with domain of mail.ru, which has the > strictest DMARC policy setting. > > So mailing list like postfix-users doesn't deliver my message to > myself on this domain. And google groups rewrite the sender address > to their own address. > > I don't know why mail.ru has this setup, this seems unfriendly. All of your posts from mail.ru pass DMARC according to my instance of OpenDMARC. If mail.ru isn't returning your posts, it's probably nothing to do with DMARC. Perhaps you can ask them. I also have strict DMARC policy and no difficulty with this list. -- Nick
Re: Question about DMARC
On Fri, 22 Nov 2019 at 08:42, Nick wrote: > On 2019-11-22 04:21 GMT, Wesley Peng wrote: > > The email I am using is with domain of mail.ru, which has the > > strictest DMARC policy setting. > > > > So mailing list like postfix-users doesn't deliver my message to > > myself on this domain. And google groups rewrite the sender address > > to their own address. > > > > I don't know why mail.ru has this setup, this seems unfriendly. > > All of your posts from mail.ru pass DMARC according to my instance of > OpenDMARC. If mail.ru isn't returning your posts, it's probably > nothing to do with DMARC. Perhaps you can ask them. I also have > strict DMARC policy and no difficulty with this list. > +1
Re: Question about DMARC
Hi the mail I sent from mail.ru to this list got dropped, I didn’t get the message I sent. On Fri, Nov 22, 2019, at 4:41 PM, Nick wrote: > On 2019-11-22 04:21 GMT, Wesley Peng wrote: > > The email I am using is with domain of mail.ru, which has the > > strictest DMARC policy setting. > > > > So mailing list like postfix-users doesn't deliver my message to > > myself on this domain. And google groups rewrite the sender address > > to their own address. > > > > I don't know why mail.ru has this setup, this seems unfriendly. > > All of your posts from mail.ru pass DMARC according to my instance of > OpenDMARC. If mail.ru isn't returning your posts, it's probably > nothing to do with DMARC. Perhaps you can ask them. I also have > strict DMARC policy and no difficulty with this list. > -- > Nick >
Re: Question about DMARC
I meant I didn’t get it in my mail.ru inbox. The other providers may or may not reject it. Thanks. On Fri, Nov 22, 2019, at 5:52 PM, Wesley Peng wrote: > Hi > > the mail I sent from mail.ru to this list got dropped, I didn’t get the > message I sent. > > > On Fri, Nov 22, 2019, at 4:41 PM, Nick wrote: >> On 2019-11-22 04:21 GMT, Wesley Peng wrote: >> > The email I am using is with domain of mail.ru, which has the >> > strictest DMARC policy setting. >> > >> > So mailing list like postfix-users doesn't deliver my message to >> > myself on this domain. And google groups rewrite the sender address >> > to their own address. >> > >> > I don't know why mail.ru has this setup, this seems unfriendly. >> >> All of your posts from mail.ru pass DMARC according to my instance of >> OpenDMARC. If mail.ru isn't returning your posts, it's probably >> nothing to do with DMARC. Perhaps you can ask them. I also have >> strict DMARC policy and no difficulty with this list. >> -- >> Nick >> >
Re: Question about DMARC
On Fri, 22 Nov 2019 at 09:56, Wesley Peng wrote: > I meant I didn’t get it in my mail.ru inbox. The other providers may or > may not reject it. Thanks. > > On Fri, Nov 22, 2019, at 5:52 PM, Wesley Peng wrote: > > Hi > > the mail I sent from mail.ru to this list got dropped, I didn’t get the > message I sent. > > > On Fri, Nov 22, 2019, at 4:41 PM, Nick wrote: > > On 2019-11-22 04:21 GMT, Wesley Peng wrote: > > The email I am using is with domain of mail.ru, which has the > > strictest DMARC policy setting. > > > > So mailing list like postfix-users doesn't deliver my message to > > myself on this domain. And google groups rewrite the sender address > > to their own address. > > > > I don't know why mail.ru has this setup, this seems unfriendly. > > All of your posts from mail.ru pass DMARC according to my instance of > OpenDMARC. If mail.ru isn't returning your posts, it's probably > nothing to do with DMARC. Perhaps you can ask them. I also have > strict DMARC policy and no difficulty with this list. > > > But I did, and I run opendmarc. So the issue is nothing to do with DMARC...
presenting TLS Client Certificates without breaking TLS to mixed MSA/MX
Hello List, is there a clean way to optionally present a client certificate to a Postfix MX configured with smtpd_tls_received_header=yes smtpd_tls_ask_ccert = yes smtpd_tls_CApath=/etc/ssl/certs without breaking the use of TLS or even the mail delivery to MXes that are verifying presented client certificates against a local CA, and rejecting anything else. I don't want to configure them all explicitly in /etc/postfix/transport. My first idea was: /etc/postfix/master.cf: smtp_ccert unix - - y - - smtp -o syslog_name=postfix/$service_name -o smtp_tls_cert_file=/etc/postfix/ssl/crt/server.crt -o smtp_tls_key_file=/etc/postfix/ssl/key/server.key /etc/postfix/main.cf: default_transport = smtp_ccert: fallback_transport = smtp: I worried a bit about penalty times in greylisting scenaries since I expected this to retry to fast, and the greylisting daemon not to notice the difference between the attempts with and without greylisting. But postfix isn't even trying with the fallback transport in this case. fallback_relay and smtp_fallback_relay shows the same behavior (isn't used). The idea behind this is to have a fully verified transport trust chain within the header when all postfix servers on the transport do this. Any ideas? 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
Re: Question about DMARC
On 11/21/19 11:47 PM, Wesley Peng wrote: > Richard Damon wrote: >> That is a question to ask them. Basically the strict DMARC policy is >> designed for transactional email, where spoofing is a real danger. The >> side effect of it is that addresses on such a domain really shouldn't be >> used on mailing lists, or any other 3rd party senders not specifically >> set up for that by the domain owner. For the proper usages of this, it >> really isn't much of a problem, as the sorts of institutions that deal >> with this sort of transactional mail, probably shouldn't be using that >> same domain for less formal usages that tends to go with a mailing list. >> >> The problems arise when a domain that doesn't really need that level of >> protection adopts it for some reason, especially if they don't inform >> their users of the implications of that decision. > > Hello Richard, > > If I am wrong, please forgive me. > > Many ISP/Registrars provide email forwarding, I even had a pobox.com > account which I used for 10+ years with just forwarding feature. > > When a mail like mail.ru was relayed by those providers, it sounds > easy to break SPF/DKIM, so the recepients may reject the message. This > is not good practice for the sender, even for mail.ru itself. > > Am I right? > > regards. > Normal forwarding will break SPF, but not DKIM (one reason DMARC uses both). A mail provider that uses strict settings but doesn't DKIM sign the messages would be considered seriously broken in my experience. The issue is that many mailing list will break DKIM by slightly modifing the message, like adding a signal word to the subject or a footer with information like unsubscribing instructions (this can be a legal requirement in some jurisdictions). Note, this list does NOT do this sort of modification, so doesn't cause that sort of problem. -- Richard Damon
Re: Question about DMARC
Dnia 22.11.2019 o godz. 10:45:42 Wesley Peng pisze: > > So mailing list makes DKIM or SPF failed? > > Thank you for your helps. My opinion is that the actual problem is that people who invented SPF and/or DMARC had wrong assumptions about how email works/should work. They assumed email is a straight and simple one-to-one communication like HTTP. If you send a mail from user1@xxx to user2@yyy, it goes straight from sending server for domain xxx to receiving server for domain yyy. So the receiving server can check if the email is coming from a "valid", "authorized" server for domain xxx (despite the fact that there isn't - and never was - such thing as "valid sending server" for any domain). This concept puts mailing lists, email forwarding and similar things completely out of scope. I would dare to say that these things simply did not exist for inventors of SPF/DMARC. That means, they obviously knew these things exist, but assumed they are completely unimportant and shouldn't (in their approach) be used. Big email providers started adopting SPF/DMARC etc. also without much thinking about these seemingly "unimportant" use cases, and then suddenly it turned out that we have quite a problem. You may disagree of course, but that's just how I see it. There is a quite old article about why SPF is wrong, but in my opinion this article didn't date a bit: http://david.woodhou.se/why-not-spf.html -- 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: Question about DMARC
Would this list break SPF then? Thanks On Fri, Nov 22, 2019, at 7:15 PM, Richard Damon wrote: > On 11/21/19 11:47 PM, Wesley Peng wrote: > > Richard Damon wrote: > >> That is a question to ask them. Basically the strict DMARC policy is > >> designed for transactional email, where spoofing is a real danger. The > >> side effect of it is that addresses on such a domain really shouldn't be > >> used on mailing lists, or any other 3rd party senders not specifically > >> set up for that by the domain owner. For the proper usages of this, it > >> really isn't much of a problem, as the sorts of institutions that deal > >> with this sort of transactional mail, probably shouldn't be using that > >> same domain for less formal usages that tends to go with a mailing list. > >> > >> The problems arise when a domain that doesn't really need that level of > >> protection adopts it for some reason, especially if they don't inform > >> their users of the implications of that decision. > > > > Hello Richard, > > > > If I am wrong, please forgive me. > > > > Many ISP/Registrars provide email forwarding, I even had a pobox.com > > account which I used for 10+ years with just forwarding feature. > > > > When a mail like mail.ru was relayed by those providers, it sounds > > easy to break SPF/DKIM, so the recepients may reject the message. This > > is not good practice for the sender, even for mail.ru itself. > > > > Am I right? > > > > regards. > > > Normal forwarding will break SPF, but not DKIM (one reason DMARC uses > both). A mail provider that uses strict settings but doesn't DKIM sign > the messages would be considered seriously broken in my experience. The > issue is that many mailing list will break DKIM by slightly modifing the > message, like adding a signal word to the subject or a footer with > information like unsubscribing instructions (this can be a legal > requirement in some jurisdictions). Note, this list does NOT do this > sort of modification, so doesn't cause that sort of problem. > > -- > Richard Damon > >
Re: Question about DMARC
No. It's how DMARC uses SPF. Scott K On November 22, 2019 11:25:47 AM UTC, Wesley Peng wrote: >Would this list break SPF then? Thanks > >On Fri, Nov 22, 2019, at 7:15 PM, Richard Damon wrote: >> On 11/21/19 11:47 PM, Wesley Peng wrote: >> > Richard Damon wrote: >> >> That is a question to ask them. Basically the strict DMARC policy >is >> >> designed for transactional email, where spoofing is a real danger. >The >> >> side effect of it is that addresses on such a domain really >shouldn't be >> >> used on mailing lists, or any other 3rd party senders not >specifically >> >> set up for that by the domain owner. For the proper usages of >this, it >> >> really isn't much of a problem, as the sorts of institutions that >deal >> >> with this sort of transactional mail, probably shouldn't be using >that >> >> same domain for less formal usages that tends to go with a mailing >list. >> >> >> >> The problems arise when a domain that doesn't really need that >level of >> >> protection adopts it for some reason, especially if they don't >inform >> >> their users of the implications of that decision. >> > >> > Hello Richard, >> > >> > If I am wrong, please forgive me. >> > >> > Many ISP/Registrars provide email forwarding, I even had a >pobox.com >> > account which I used for 10+ years with just forwarding feature. >> > >> > When a mail like mail.ru was relayed by those providers, it sounds >> > easy to break SPF/DKIM, so the recepients may reject the message. >This >> > is not good practice for the sender, even for mail.ru itself. >> > >> > Am I right? >> > >> > regards. >> > >> Normal forwarding will break SPF, but not DKIM (one reason DMARC uses >> both). A mail provider that uses strict settings but doesn't DKIM >sign >> the messages would be considered seriously broken in my experience. >The >> issue is that many mailing list will break DKIM by slightly modifing >the >> message, like adding a signal word to the subject or a footer with >> information like unsubscribing instructions (this can be a legal >> requirement in some jurisdictions). Note, this list does NOT do this >> sort of modification, so doesn't cause that sort of problem. >> >> -- >> Richard Damon >> >>
Re: Question about DMARC
On Fri, 22 Nov 2019 at 11:26, Jaroslaw Rafa wrote: > Dnia 22.11.2019 o godz. 10:45:42 Wesley Peng pisze: > > > > So mailing list makes DKIM or SPF failed? > > > > Thank you for your helps. > > My opinion is that the actual problem is that people who invented SPF > and/or > DMARC had wrong assumptions about how email works/should work. > > They assumed email is a straight and simple one-to-one communication like > HTTP. If you send a mail from user1@xxx to user2@yyy, it goes straight > from > sending server for domain xxx to receiving server for domain yyy. So the > receiving server can check if the email is coming from a "valid", > "authorized" server for domain xxx (despite the fact that there isn't - and > never was - such thing as "valid sending server" for any domain). > > This concept puts mailing lists, email forwarding and similar things > completely out of scope. I would dare to say that these things simply did > not > exist for inventors of SPF/DMARC. That means, they obviously knew these > things exist, but assumed they are completely unimportant and shouldn't (in > their approach) be used. > > Big email providers started adopting SPF/DMARC etc. also without much > thinking about these seemingly "unimportant" use cases, and then suddenly > it > turned out that we have quite a problem. > > You may disagree of course, but that's just how I see it. There is a quite > old article about why SPF is wrong, but in my opinion this article didn't > date a bit: http://david.woodhou.se/why-not-spf.html The limitations you describe affect SPF but not DMARC because DMARC can rely *either* on SPF *or* on DKIM. There are limitations on DKIM through mailing lists which depend on the mailing list settings and on which headers that the sender has chosen to sign. However sensibly-designed mailing lists (like this one) can work with DKIM-signed emails where the signed headers are not specified too aggressively, and so should still pass DMARC testing (i.e. DKIM + DKIM-alignment both pass).
Re: Question about DMARC
On 11/22/19 6:25 AM, Jaroslaw Rafa wrote: > Dnia 22.11.2019 o godz. 10:45:42 Wesley Peng pisze: >> So mailing list makes DKIM or SPF failed? >> >> Thank you for your helps. > My opinion is that the actual problem is that people who invented SPF and/or > DMARC had wrong assumptions about how email works/should work. > > They assumed email is a straight and simple one-to-one communication like > HTTP. If you send a mail from user1@xxx to user2@yyy, it goes straight from > sending server for domain xxx to receiving server for domain yyy. So the > receiving server can check if the email is coming from a "valid", > "authorized" server for domain xxx (despite the fact that there isn't - and > never was - such thing as "valid sending server" for any domain). > > This concept puts mailing lists, email forwarding and similar things > completely out of scope. I would dare to say that these things simply did not > exist for inventors of SPF/DMARC. That means, they obviously knew these > things exist, but assumed they are completely unimportant and shouldn't (in > their approach) be used. > > Big email providers started adopting SPF/DMARC etc. also without much > thinking about these seemingly "unimportant" use cases, and then suddenly it > turned out that we have quite a problem. > > You may disagree of course, but that's just how I see it. There is a quite > old article about why SPF is wrong, but in my opinion this article didn't > date a bit: http://david.woodhou.se/why-not-spf.html Base SPF works through a traditional forwarder, because the base rules for SPF allow the message to pass based on the domain of the Sender: header, not just the From:. A proper forwarder will add a Sender: header for itself, to indicate that while it was not the originator of the message, it was the last one to send it. DMARC changes the rules for SPF, and says that the message must align with the From: header, based on the idea that most mail readers don't show you that sender does not equal from. SPF works just fine as designed, because it was designed as a HELPER for receivers, not intending to be an all encompassing solution. If I, the receiver of the message see that the message passed SPF, AND I trust the domain that sent the message, then I can be fairly sure that the message is legitimate. If there is a problem with the message, because I trust the domain, I feel I can report the issue and it will be dealt with. SPF is designed to help with 'white-listing'. SPF helps fight spam, as I can white list the major mail agents that do a good job filtering spam, and then have more bandwidth to look at those for sources I don't know. DMARC adds nothing to that ability. Anyone can create a domain with a strict DMARC policy and send spam from it. Just passing DMARC means nothing in regards to the spamyness of a message. What DMARC is designed to fight is forgeries. If you setup DMARC for your domain, then people can trust that a message that says it is from you is from you (it still could be spam though). The 'cost' of using DMARC is that you limit what users of that domain can do, as they can't use external re-mailers that don't follow very specific guidelines. This works for domains that deal with transactional emails, where forgeries can be important, it doesn't work for more casual usage. I would actually say that an email provider using strict DMARC is actually a sign of a email provider with a problem. I have heard that the reason that Yahoo at least adopted it was that they had so many security breaches that leaked out their users address books, that a very real problem was yahoo members getting emails claiming to be from friends that were actually attack vectors, that they couldn't keep up with other measures to try and block it. The adoption of DMARC for a general email provider is basically an acknowledgement that they have problems maintaining a safe and secure email system. IF they advertise it as a feature, and explain what it means you can't do, then maybe it isn't, but if they don't inform you that they are not suitable for many mailing lists and the like, then likely THEY are the one with a problem. -- Richard Damon
Re: Question about DMARC
Dnia 22.11.2019 o godz. 11:40:29 Dominic Raferd pisze: > > The limitations you describe affect SPF but not DMARC because DMARC can > rely *either* on SPF *or* on DKIM. But it probably depends on how the *recipient* configured DMARC checking and the sender can't do anything about it - am I right? Recently I was forced to set up both SPF *and* DKIM on outgoing mail (I still don't verify SPF, DKIM nor DMARC on incoming mail and don't plan to) because someone set up a DMARC record at my parent domain, eu.org, and Google started using this DMARC record to verify messages coming from my domain rafa.eu.org (which it shouldn't do because eu.org is a "public suffix" - anybody can register their subdomain under eu.org - so my domain "rafa.eu.org" is an "organizational domain" in terms of DMARC, ie. the receiver should not look for DMARC records above that domain). Because I didn't have neither SPF nor DKIM, my messages started to fail DMARC tests at Gmail (which could be probably one of the reasons Gmail started to put my messages to recipients' spam folders - I'm not sure because I did many different things trying to resolve the issue and get out of spam folder, so I'm not sure what actually helped). Configuring SPF alone didn't help - Gmail still indicated DMARC as failed, I had to configure both SPF and DKIM to satisfy it. BTW, as I don't like SPF, I configured my SPF record with "?all" at the end, which means "I have no opinion about other IP addresses sending mail for my domain, do whatever you would otherwise do with them". I think this is the proper way SPF should be used, if it must be used at all. The currently omnipresent "-all" at end of SPF records is in my opinion justified in only one case: when it's the only item SPF record specifies, ie. the domain declares it sends no mail at all. And it's the only case when receivers should strictly respect SPF and outright reject all mail coming from such domains. In all other cases, if the domain sends *any* mail, that mail can be forwarded; so "-all" doesn't make sense. -- 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: Question about DMARC
Dnia 22.11.2019 o godz. 07:24:03 Richard Damon pisze: > > Base SPF works through a traditional forwarder, because the base rules > for SPF allow the message to pass based on the domain of the Sender: > header, not just the From:. A proper forwarder will add a Sender: header > for itself, to indicate that while it was not the originator of the > message, it was the last one to send it. AFAIK no mainstream MTA adds the "Sender:" header when forwarding mail, either via .forward file, via /etc/aliases, virtual users table of any other means. Postfix doesn't do it as well. You need probably to forward via some specially crafted script to achieve this. > SPF works just fine as designed, because it was designed as a HELPER for > receivers, not intending to be an all encompassing solution. If I, the > receiver of the message see that the message passed SPF, AND I trust the > domain that sent the message, then I can be fairly sure that the message > is legitimate. So I guess SPF should be used in such a way that it adds the message a "positive" score (ie. non-spam - in most spam filtering software it's actually a negative number :)) if SPF passes, and if it fails, it's simply ignored and other criteria are used to determine if the message is spam or non-spam? Yes, I would agree with such use of SPF. But in reality it is much often used in exactly opposite way, ie. the message gets some spam score if SPF fails, but if it passes, it's usually just zero. > SPF is designed to help with 'white-listing'. But it's now used mostly for blacklisting, ie. if you fail SPF check, you are a suspected spammer. At least that's what Google and Microsoft do (and probably a couple of other big email providers as well). > the reason that Yahoo at least adopted it was that they had so many > security breaches that leaked out their users address books, that a very > real problem was yahoo members getting emails claiming to be from > friends that were actually attack vectors, that they couldn't keep up > with other measures to try and block it. Yes, that is true. On a mail server which I administered a few years ago, we had so many spam and phishing messages coming apparently from Yahoo domain that I had to take extreme measures and reject mail from that domain altogether. However, in the rejection message I put a link to a web page where one could whitelist him/herself by submitting their e-mail address via the page. A legitimate sender would - hopefully - do it and thus be able to re-send the message. The spammer usually won't, as they don't read rejection messages, and even if they did, they won't have time to deal with this procedure. -- 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: Question about DMARC
On Fri, 22 Nov 2019 at 12:45, Jaroslaw Rafa wrote: > Dnia 22.11.2019 o godz. 11:40:29 Dominic Raferd pisze: > > > > The limitations you describe affect SPF but not DMARC because DMARC can > > rely *either* on SPF *or* on DKIM. > > But it probably depends on how the *recipient* configured DMARC checking > and > the sender can't do anything about it - am I right? > > Recently I was forced to set up both SPF *and* DKIM on outgoing mail (I > still don't verify SPF, DKIM nor DMARC on incoming mail and don't plan to) > because someone set up a DMARC record at my parent domain, eu.org, and > Google started using this DMARC record to verify messages coming from my > domain rafa.eu.org (which it shouldn't do because eu.org is a "public > suffix" - anybody can register their subdomain under eu.org - so my domain > "rafa.eu.org" is an "organizational domain" in terms of DMARC, ie. the > receiver should not look for DMARC records above that domain). Because I > didn't have neither SPF nor DKIM, my messages started to fail DMARC tests > at > Gmail (which could be probably one of the reasons Gmail started to put my > messages to recipients' spam folders - I'm not sure because I did many > different things trying to resolve the issue and get out of spam folder, so > I'm not sure what actually helped). Configuring SPF alone didn't help - > Gmail still indicated DMARC as failed, I had to configure both SPF and DKIM > to satisfy it. > > BTW, as I don't like SPF, I configured my SPF record with "?all" at the > end, > which means "I have no opinion about other IP addresses sending mail for my > domain, do whatever you would otherwise do with them". I think this is the > proper way SPF should be used, if it must be used at all. The currently > omnipresent "-all" at end of SPF records is in my opinion justified in only > one case: when it's the only item SPF record specifies, ie. the domain > declares it sends no mail at all. And it's the only case when receivers > should strictly respect SPF and outright reject all mail coming from such > domains. In all other cases, if the domain sends *any* mail, that mail can > be forwarded; so "-all" doesn't make sense. > I am very surprised to hear that such a big (and generally competent) provider as Gmail would misapply DMARC. Nevertheless as I read the RFC at 3.2 and 6.6.3 I agree that the process of locating a DMARC record should not proceed below the Organizational Domain which in your case would be [n]. eu.org (based on latest from https://publicsuffix.org/list/public_suffix_list.dat). My guess is that the Gmail code just carries on stripping labels from the left-hand side of the domain address and testing what is left until it finds a DMARC record, hence it finds the record that should not be, but is, published for eu.org. Or they may use a different source for their public suffix list. Even so, the eu.org DMARC policy is 'none' so it is *not* advising receiver to quarantine or block emails that fail the DMARC policy (which begs the question of why bother with a DMARC policy at all of course). I suppose it is possible that Gmail use a DMARC fail even with p=none as a point-score in their internal algorithm to determine whether to move an email to a recipient's spam folder. BTW, I dislike SPF too!
Re: Question about DMARC
Dnia 22.11.2019 o godz. 13:16:41 Dominic Raferd pisze: > Even so, the eu.org DMARC policy is 'none' so it is *not* advising receiver > to quarantine or block emails that fail the DMARC policy (which begs the > question of why bother with a DMARC policy at all of course). Many domains have DMARC policy with p=none (I did this as well). Maybe just because Google is pushing people to do this? They have the following in their sender guidelines ( https://support.google.com/mail/answer/81126?hl=en ): =quote begin= Step 3: Make sure emails don't get marked as spam Authenticate your mail Emails without authentication often get email blocked or marked as spam to protect recipients from phishing scams. Unauthenticated emails with attachments might get completely rejected for security reasons. To ensure Gmail can authenticate you: Send from the same IP address. Keep valid reverse DNS records of your IP address that point to your domain. Choose the same address in the "From:" header for every message. Other recommendations Sign messages with DKIM. We don't authenticate messages signed with keys that use fewer than 1024 bits. Publish a SPF record. Publish a DMARC policy. =quote end= So if anybody has deliverability issues with Gmail and refers to that guide, they tell you you should set up SPF, DKIM and DMARC. -- 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: Question about DMARC
On 22.11.19 06:15, Richard Damon wrote: Normal forwarding will break SPF, note that by "normal forwarding" Richard meant the old-school "re-send mail to new recipient, keep its contents and the envelope sender" where the keeping envelope sender is what breaks SPF. This is imho valid, because at forwarding time, it's already not the original envelope sender who sends the mail - in fact it's the original recipient who forwards it. So, if an error occurs after forwardins, it's not the original sender who should get notification, but the recipient who has forwarded it. The SRS method was designed to avoid this problem, add the original sender to the envelope address, so forwarding MTA (or whoever) This mailing list does not break SPF, because it re-sends mail using envelope sender "owner-postfix-us...@postfix.org". The issue is that many mailing list will break DKIM by slightly modifing the message, like adding a signal word to the subject or a footer with information like unsubscribing instructions (this can be a legal requirement in some jurisdictions). Note, this list does NOT do this sort of modification, so doesn't cause that sort of problem. ...and even adding this information to list mail doesn't prevent some subscribed users from complaining about getting the mail. Unfortunately, MUA support of maling lists is not very common. -- 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. M$ Win's are shit, do not use it !
Re: Question about DMARC
On 22.11.19 07:24, Richard Damon wrote: Base SPF works through a traditional forwarder, because the base rules for SPF allow the message to pass based on the domain of the Sender: header, not just the From:. A proper forwarder will add a Sender: header for itself, to indicate that while it was not the originator of the message, it was the last one to send it. DMARC changes the rules for SPF, and says that the message must align with the From: header, based on the idea that most mail readers don't show you that sender does not equal from. SPF is designed to work with envelope addresses, not headers. Any forwarder that keeps envelope address (which is common for .forward files or MTA-level mail aliases) thus breaks spf unless measures are made. And this it the main problem with SPF enforcement. -- 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. I wonder how much deeper the ocean would be without sponges.
Sieve vacation and smtp_sasl_password_maps
Hi, I've set up sieve vacation reply but my postfix setup is using smtp_sasl_password_maps and smtp_sender_dependent_authentication. The problem is that Sieve will send the reply with "from=<>" to prevent bounces. This means that Postfix has no way to authenticate to my ISP because it doesn't find the sender entry on the sasl DB. How can I use both features toghether? Thanks in advance! Gianni
Re: Reject Chinese mail
* merr...@fn.de: > We did get a lot of spam messages from Chinese providers. We speak not > Chinese, do you think if it is possible to reject all mails from > China? SpamAssassin, which is often used in combination with Postfix, has a plugin called "RelayCountry" that allows you to change the spam score of email. It uses GeoIP and is therefore not always accurate, but overall it can help. There is also the "TextCat" plugin that attempts to determine the language of email bodies, and it allows you to adjust spam scores based on wanted/unwanted languages. Personally, I think that hard blocks based on these plugins are not a good idea, but if your business is not set up to handle communication written in language X (e.g. because none of your employees speak X), adjusting the spam score seems reasonable. -Ralph
Re: presenting TLS Client Certificates without breaking TLS to mixed MSA/MX
* 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. When acting as an SMTP client, Postfix should present the certificate you have defined via smtp_tls_cert_file if the receiving Postfix (the SMTP server) uses smtpd_tls_ask_ccert=yes. That matches your example settings. 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. -Ralph
Re: presenting TLS Client Certificates without breaking TLS to mixed MSA/MX
On Fri, Nov 22, 2019 at 12:11:21PM +0100, Lars Kollstedt wrote: > Is there a clean way to optionally present a client certificate to a > Postfix MX without breaking the use of TLS or even the mail delivery > to MXes that are verifying presented client certificates against a > local CA, and rejecting anything else. Have you recently seen MX hosts that solicit client certs and then abort the TLS handshake when these don't verify? 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 don't want to configure them all explicitly in /etc/postfix/transport. You certainly can't blacklist all the bad sites, and so the right answer is to whitelist only the sites to which you need to present client certs. > My first idea was: > /etc/postfix/master.cf: > smtp_ccert unix - - y - - smtp > -o syslog_name=postfix/$service_name > -o smtp_tls_cert_file=/etc/postfix/ssl/crt/server.crt > -o smtp_tls_key_file=/etc/postfix/ssl/key/server.key > > /etc/postfix/main.cf: > default_transport = smtp_ccert: > fallback_transport = smtp: 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. > But postfix isn't even trying with the fallback transport in this case. As expected. > The idea behind this is to have a fully verified transport trust chain within > the header when all postfix servers on the transport do this. 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. 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. It is not clear this is needed. -- Viktor.
Re: Reject Chinese mail
SA (Spamassassin) is good idea, I saw most people running their own mail servers are using it. On Sat, Nov 23, 2019, at 4:35 AM, Ralph Seichter wrote: > * merr...@fn.de: > > > We did get a lot of spam messages from Chinese providers. We speak not > > Chinese, do you think if it is possible to reject all mails from > > China? > > SpamAssassin, which is often used in combination with Postfix, has a > plugin called "RelayCountry" that allows you to change the spam score of > email. It uses GeoIP and is therefore not always accurate, but overall > it can help. > > There is also the "TextCat" plugin that attempts to determine the > language of email bodies, and it allows you to adjust spam scores based > on wanted/unwanted languages. > > Personally, I think that hard blocks based on these plugins are not a > good idea, but if your business is not set up to handle communication > written in language X (e.g. because none of your employees speak X), > adjusting the spam score seems reasonable. > > -Ralph >
Validation DMARC
Hi when validating DMARC, it use the envelop address, or use from address from the header? Thanks
Re: Validation DMARC
On 11/22/19 7:12 PM, Wesley Peng wrote: > Hi > > when validating DMARC, it use the envelop address, or use from address > from the header? Thanks > DMARC specifically says that validation is to be based on the From: Header of the message (which is different than how SPF and DKIM work by themselves). This is what gives DMARC issues with some uses of emails when messages pass through relays which do things that break the message in route to their final destination. The email RFCs say that the From: header is suppose to indicate the author of the message, and the minor modifications along the way done by the relays does not invalidate who the author is, so the From should be retain. Basically, this means that those domains that use DMARC, especially at the higher levels, should not use those types of relays, which makes some sense for the original intent of DMARC. -- Richard Damon
Re: Reject Chinese mail
merr...@fn.de writes: > [...] do you think if it is possible to reject all mails from China? Thanks How about moving to Gmail(Google Apps)? Gmail's spam defense is not bad, i think. Plus don't block China. Blocking China is blocking money. Sincerely, -- ^고맙습니다 _地平天成_ 감사합니다_^))//
Re: Question about DMARC
On 11/22/19 6:25 AM, Wesley Peng wrote: > Would this list break SPF then? Thanks > This list sends with an envelope sender in the lists domain, so it doesn't break general SPF, it will break DMARC SPF, since that check SPF only to the From: domain. This list doesn't modify messages in a way to break DKIM, so messages that were DKIM signed to the From: Domain will still pass DMARC DKIM, so will pass DMARC (unless the domain doesn't DKIM sign messages, which would be very unusual for highly restricted DMARC). -- Richard Damon
Re: Question about DMARC
Thanks for helps. On Sat, Nov 23, 2019, at 11:07 AM, Richard Damon wrote: > On 11/22/19 6:25 AM, Wesley Peng wrote: > > Would this list break SPF then? Thanks > > > This list sends with an envelope sender in the lists domain, so it > doesn't break general SPF, it will break DMARC SPF, since that check SPF > only to the From: domain. > > This list doesn't modify messages in a way to break DKIM, so messages > that were DKIM signed to the From: Domain will still pass DMARC DKIM, so > will pass DMARC (unless the domain doesn't DKIM sign messages, which > would be very unusual for highly restricted DMARC). > > -- > Richard Damon > >
