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 > >
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
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.
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
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 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. 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
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
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
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
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
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
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
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 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...
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
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 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
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
> Am I right? Yes Wesley you are right. So i don't like DMARC (with SPF). Sincerely, -- ^고맙습니다 _地平天成_ 감사합니다_^))//
Re: Question about DMARC
Richard Damon wrote: The side effect of it is that addresses on such a domain really shouldn't be used on mailing lists, Thanks for pointing out this. I never knew it. Now I changed my mail to fastmail account, which I owned it for many years. I just don't like its mobile app, it's just a web wrapper, not as good as gmail/mail.ru etc. After I checked I think fastmail will do well on receiving mailing list. Thanks.
Re: Question about DMARC
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.
Re: Question about DMARC
On 11/21/19 11:21 PM, Wesley Peng wrote: > Richard Damon wrote: >> The typical options for the mailing list are >> >> 1) Just not allow people from such domains to post to the list (the >> reject option you mention) >> >> 2) Rewrite the from address from people from such a domain to be from >> the domain of the list (often the list address). This is arguably >> discouraged by the email RFCs, as the from address should indicate the >> AUTHOR of the message, which is the original sender. It also can cause >> problems with identifying who sent the message, and can corrupt peoples >> address books if their program records that address as being associated >> with the sender. It can also make it harder to reply just to the sender. >> >> 3) Rewrite the message by wrapping it as an attachment, with the outer >> message being from the list. This has the problem that many clients >> won't handle the message in a useful manner. > > Thank you Richard. > > 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. > > Thanks. > 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. -- Richard Damon
Re: Question about DMARC
Richard Damon wrote: The typical options for the mailing list are 1) Just not allow people from such domains to post to the list (the reject option you mention) 2) Rewrite the from address from people from such a domain to be from the domain of the list (often the list address). This is arguably discouraged by the email RFCs, as the from address should indicate the AUTHOR of the message, which is the original sender. It also can cause problems with identifying who sent the message, and can corrupt peoples address books if their program records that address as being associated with the sender. It can also make it harder to reply just to the sender. 3) Rewrite the message by wrapping it as an attachment, with the outer message being from the list. This has the problem that many clients won't handle the message in a useful manner. Thank you Richard. 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. Thanks.
Re: Question about DMARC
On 11/21/19 9:45 PM, Wesley Peng wrote: > Greetings, > > When mail is relayed through mailing list, why the DMARC policy is > possible to reject? > > For example, I sent mail from x...@mail.ru to y...@googlegroups.com > > Since mail.ru has the strictest DMARC policy, the recepients may > choose to reject this mail which is relayed by googlegroups, the > reason is due to DKIM or SPF fails. > > So mailing list makes DKIM or SPF failed? > > Thank you for your helps. > > Regards. > The issue is that the way many mailing list work, if a person from a domain with strict DMARC policy sends a message to the mailing list, and it is altered in a way that makes it fail DKIM, (and it will fail SPF), so any attempted recipient from a domain that honors the DMARC policy will send a reject DSN to the mailing list, which may cause those recipients to get unsubscribed due to undeliverable mail. It would seem unfair to punish the recipient for something they didn't do wrong, sending the reject DSN is the appropriate result. The real error is arguably the sending of an email to a mailing list from a domain that by its policies doesn't allow the use of that type of mailing list. The typical options for the mailing list are 1) Just not allow people from such domains to post to the list (the reject option you mention) 2) Rewrite the from address from people from such a domain to be from the domain of the list (often the list address). This is arguably discouraged by the email RFCs, as the from address should indicate the AUTHOR of the message, which is the original sender. It also can cause problems with identifying who sent the message, and can corrupt peoples address books if their program records that address as being associated with the sender. It can also make it harder to reply just to the sender. 3) Rewrite the message by wrapping it as an attachment, with the outer message being from the list. This has the problem that many clients won't handle the message in a useful manner. -- Richard Damon
Question about DMARC
Greetings, When mail is relayed through mailing list, why the DMARC policy is possible to reject? For example, I sent mail from x...@mail.ru to y...@googlegroups.com Since mail.ru has the strictest DMARC policy, the recepients may choose to reject this mail which is relayed by googlegroups, the reason is due to DKIM or SPF fails. So mailing list makes DKIM or SPF failed? Thank you for your helps. Regards.
