Re: [dmarc-ietf] Solving DMARC damage with User quarantine and Steram-Info tag
As of last Christmas, I am on 100% validation of Mail From:. Previously unseen domains that cannot produce SPF PASS go to system quarantine. After review, acceptable messages get a local policy to provide alternate positive identification, usually of the form:. server domain name, fcDNS on server name, and Mail From domain. This solves the identification problem without whitelisting, so messages still have to pass content filtering. Unacceptable messages get blacklisted. Either way, the authentication problem does not need to be revisited for that domain. In a few cases, I have solved SPF problems by trusting any domain on a particular server platform. It adds risk, but reduces the level of effort wasted on lower risks, so I can concentrate on higher risks. I am not yet on 100% From validationm I don't know if I will ever get there, but my framework could support it in theory. Right now, a lot of smaller ESP traffic gets through without From verification, as long as it passes content filtering. I am filtering for my own organization, so I have to make the CEO happy while keeping the organization free of devastating malware. I had to build a custom Sender Authentication process because I could not buy it anywhere But this group is not interested in the general authentication problem. It is only interested in the tiny subset of mail with DMARC p=reject. That scope definition has been a big disappointment for me. Doug On Tue, Apr 4, 2023, 12:31 AM Jesse Thompson wrote: > On Mon, Apr 3, 2023, at 8:30 PM, Douglas Foster wrote: > > I described my algorithm because I am surprised that some of these > sub-optimal filtering problems exist. > > > I would have thought the DKIM domain to be a better authenticated > identifier than MailFrom domain; messages from ESPs are typically > double-signed with DKIM (giving the evaluator the choice/multiple signals), > but can have only one MailFrom and that can be either the ESP's domain or > the customer's (depending on their ability to delegate via DNS). > > Let's not cast judgement. It's an issue of lack of mutual understanding. > > > As a corollary: In an American bar, the bouncer checks I.Ds. on the way > in, so that the bartender does not have to check IDs on every drink. > Similarly, I assume that a major ESP has compelling business practices to > ensure that the From address on an outbound message matches the account > used to domain used to sign up for service.Therefore, I don't have to > recheck identity because the identity has been (or should have been) > checked by the ESP. I have opted to delegate authentication trust to the > ESP, until they betray me. We can't put that approach in an IETF > standard, but we could put it into a Best Practices document. But I am > surprised that we would need to do so. I expect anyone that is trying to > filter traffic correctly to come to a similar conclusion, because the > volume of unsigned mail from ESPs is enormous. You cannot justify blocking > it all and you cannot investigate every one. > > > A better analogy is if the bouncers were not employed by the same > organization as the bartenders. What kind of contract between the bouncer > firms and the bar owner is required? > > > Yes, for most ESP traffic, the ESP is in the MailFrom domain and passes > SPF, usually on against server with the same domain that passes fcDNS. So > ESP identification is not a concern for me. > > > I'm not seeing how you identify an ESP from not an ESP > > > I only use DKIM to assess the From address. > > > Assuming you are talking about DMARC logic here. > > If the message isn't DKIM aligned or SPF aligned, yet came from an ESP, > what do you conclude with your assessment? > > > Your "intent" parameters and my "operating practices" seem to be pursuing > the same goal: establishing trust by defining metrics that can be verified > over time. > > > ++ > > Jesse > > > > Doug > > > > On Mon, Apr 3, 2023 at 7:00 PM Jesse Thompson wrote: > > > On Sat, Apr 1, 2023, at 9:41 PM, Douglas Foster wrote: > > My approach to ESP traffic is simple. I assume that the ESP has > authorized the account indicated by the From address, so I don't worry > about Sender Authentication as long as the message passes SPF based on the > ESP domain. DMARC is about identity verification, and I am counting on > the ESP to ensure that identity verification. > > > What you're describing looks like a black box (e.g. should I assume that > you don't use DKIM, only SPF, to identify the ESP?). > > So, you might resolve the identity to the message's author (despite there > being no authentication mechanism to do so), or you might not. And every > other receiver has their own logic (if any). > > > ESPs develop a reputation with me based on their ability to vet their > clients appropriately. > > > Do we need a set of best practices for ESPs to appropriately vet clients > before emitting email that otherwise carries no authenticated identifier >
Re: [dmarc-ietf] Solving DMARC damage with User quarantine and Steram-Info tag
On Mon, Apr 3, 2023, at 8:30 PM, Douglas Foster wrote: > I described my algorithm because I am surprised that some of these > sub-optimal filtering problems exist. I would have thought the DKIM domain to be a better authenticated identifier than MailFrom domain; messages from ESPs are typically double-signed with DKIM (giving the evaluator the choice/multiple signals), but can have only one MailFrom and that can be either the ESP's domain or the customer's (depending on their ability to delegate via DNS). Let's not cast judgement. It's an issue of lack of mutual understanding. > As a corollary: In an American bar, the bouncer checks I.Ds. on the way in, > so that the bartender does not have to check IDs on every drink. Similarly, > I assume that a major ESP has compelling business practices to ensure that > the From address on an outbound message matches the account used to domain > used to sign up for service.Therefore, I don't have to recheck identity > because the identity has been (or should have been) checked by the ESP. I > have opted to delegate authentication trust to the ESP, until they betray me. > We can't put that approach in an IETF standard, but we could put it into a > Best Practices document. But I am surprised that we would need to do so. > I expect anyone that is trying to filter traffic correctly to come to a > similar conclusion, because the volume of unsigned mail from ESPs is > enormous. You cannot justify blocking it all and you cannot investigate > every one. A better analogy is if the bouncers were not employed by the same organization as the bartenders. What kind of contract between the bouncer firms and the bar owner is required? > Yes, for most ESP traffic, the ESP is in the MailFrom domain and passes SPF, > usually on against server with the same domain that passes fcDNS. So ESP > identification is not a concern for me. I'm not seeing how you identify an ESP from not an ESP > I only use DKIM to assess the From address. Assuming you are talking about DMARC logic here. If the message isn't DKIM aligned or SPF aligned, yet came from an ESP, what do you conclude with your assessment? > Your "intent" parameters and my "operating practices" seem to be pursuing the > same goal: establishing trust by defining metrics that can be verified over > time. ++ Jesse > > Doug > > > > On Mon, Apr 3, 2023 at 7:00 PM Jesse Thompson wrote: >> __ >> On Sat, Apr 1, 2023, at 9:41 PM, Douglas Foster wrote: >>> My approach to ESP traffic is simple. I assume that the ESP has authorized >>> the account indicated by the From address, so I don't worry about Sender >>> Authentication as long as the message passes SPF based on the ESP domain. >>> DMARC is about identity verification, and I am counting on the ESP to >>> ensure that identity verification. >> >> What you're describing looks like a black box (e.g. should I assume that you >> don't use DKIM, only SPF, to identify the ESP?). >> >> So, you might resolve the identity to the message's author (despite there >> being no authentication mechanism to do so), or you might not. And every >> other receiver has their own logic (if any). >> >> >>> ESPs develop a reputation with me based on their ability to vet their >>> clients appropriately. >> >> Do we need a set of best practices for ESPs to appropriately vet clients >> before emitting email that otherwise carries no authenticated identifier >> aligned to the rfc5322.From? >> >> Are we conflating "predicting whether their intentions are good and will not >> stray" with "verifying they are otherwise capable of sending authenticated >> mail from the address"? I'm not sure it's fair to insist that trust is a >> prerequisite just for communicating authenticated identifiers. The ESP (or >> intermediary) mostly needs to know if sending unaligned email is going to >> cause a problem; not that they are trying to absolve itself from other >> problems. >> >> >>> (Right now my biggest spam problem comes from Gmail.com accounts that are >>> verifiably identified but being misused. Identity verification is not the >>> solution to all spam problems, it is just the one that is easiest to >>> address with standards.) >> >> The abuse might be coming via Gmail's authenticated identifiers, or it might >> be coming from an ESP's authenticated identifiers. It's still the same >> spammer (or compromised account) in both cases. Why would we not want a >> standard that can attribute the abuse to the gmail.com identity? Just >> because the domain is used by normal users? >> >> >>> On the specifics of your proposal, I am unclear what types of "intent" you >>> would put into a client profile. >> >> Something along the lines of: This is the rfc5322.from, verified by X, >> expected volume/patterns, expected nature/category(ies) of content, >> recipients are confirmed opt-in, supported feedback mechanisms, has >>
Re: [dmarc-ietf] Solving DMARC damage with User quarantine and Steram-Info tag
I described my algorithm because I am surprised that some of these sub-optimal filtering problems exist. As a corollary: In an American bar, the bouncer checks I.Ds. on the way in, so that the bartender does not have to check IDs on every drink. Similarly, I assume that a major ESP has compelling business practices to ensure that the From address on an outbound message matches the account used to domain used to sign up for service.Therefore, I don't have to recheck identity because the identity has been (or should have been) checked by the ESP. I have opted to delegate authentication trust to the ESP, until they betray me. We can't put that approach in an IETF standard, but we could put it into a Best Practices document. But I am surprised that we would need to do so. I expect anyone that is trying to filter traffic correctly to come to a similar conclusion, because the volume of unsigned mail from ESPs is enormous. You cannot justify blocking it all and you cannot investigate every one. Yes, for most ESP traffic, the ESP is in the MailFrom domain and passes SPF, usually on against server with the same domain that passes fcDNS. So ESP identification is not a concern for me. I only use DKIM to assess the >From address. Your "intent" parameters and my "operating practices" seem to be pursuing the same goal: establishing trust by defining metrics that can be verified over time. Doug On Mon, Apr 3, 2023 at 7:00 PM Jesse Thompson wrote: > On Sat, Apr 1, 2023, at 9:41 PM, Douglas Foster wrote: > > My approach to ESP traffic is simple. I assume that the ESP has > authorized the account indicated by the From address, so I don't worry > about Sender Authentication as long as the message passes SPF based on the > ESP domain. DMARC is about identity verification, and I am counting on > the ESP to ensure that identity verification. > > > What you're describing looks like a black box (e.g. should I assume that > you don't use DKIM, only SPF, to identify the ESP?). > > So, you might resolve the identity to the message's author (despite there > being no authentication mechanism to do so), or you might not. And every > other receiver has their own logic (if any). > > > ESPs develop a reputation with me based on their ability to vet their > clients appropriately. > > > Do we need a set of best practices for ESPs to appropriately vet clients > before emitting email that otherwise carries no authenticated identifier > aligned to the rfc5322.From? > > Are we conflating "predicting whether their intentions are good and will > not stray" with "verifying they are otherwise capable of sending > authenticated mail from the address"? I'm not sure it's fair to insist that > trust is a prerequisite just for communicating authenticated identifiers. > The ESP (or intermediary) mostly needs to know if sending unaligned email > is going to cause a problem; not that they are trying to absolve itself > from other problems. > > > (Right now my biggest spam problem comes from Gmail.com accounts that are > verifiably identified but being misused. Identity verification is not the > solution to all spam problems, it is just the one that is easiest to > address with standards.) > > > The abuse might be coming via Gmail's authenticated identifiers, or it > might be coming from an ESP's authenticated identifiers. It's still the > same spammer (or compromised account) in both cases. Why would we not want > a standard that can attribute the abuse to the gmail.com identity? Just > because the domain is used by normal users? > > > On the specifics of your proposal, I am unclear what types of "intent" > you would put into a client profile. > > > Something along the lines of: This is the rfc5322.from, verified by X, > expected volume/patterns, expected nature/category(ies) of content, > recipients are confirmed opt-in, supported feedback mechanisms, has > one-click-unsubscribe, etc. Basically all of the things that are discussed > when giving deliverability guidance to someone building a new email > program, but more tangible and useful for all parties. > > But it might depend on the use case. Such as indirect mail, which is what > you're getting at with Stream-Info, I think. > > Jesse > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Solving DMARC damage with User quarantine and Steram-Info tag
On Sat, Apr 1, 2023, at 9:41 PM, Douglas Foster wrote: > My approach to ESP traffic is simple. I assume that the ESP has authorized > the account indicated by the From address, so I don't worry about Sender > Authentication as long as the message passes SPF based on the ESP domain. > DMARC is about identity verification, and I am counting on the ESP to ensure > that identity verification. What you're describing looks like a black box (e.g. should I assume that you don't use DKIM, only SPF, to identify the ESP?). So, you might resolve the identity to the message's author (despite there being no authentication mechanism to do so), or you might not. And every other receiver has their own logic (if any). > ESPs develop a reputation with me based on their ability to vet their clients > appropriately. Do we need a set of best practices for ESPs to appropriately vet clients before emitting email that otherwise carries no authenticated identifier aligned to the rfc5322.From? Are we conflating "predicting whether their intentions are good and will not stray" with "verifying they are otherwise capable of sending authenticated mail from the address"? I'm not sure it's fair to insist that trust is a prerequisite just for communicating authenticated identifiers. The ESP (or intermediary) mostly needs to know if sending unaligned email is going to cause a problem; not that they are trying to absolve itself from other problems. > (Right now my biggest spam problem comes from Gmail.com accounts that are > verifiably identified but being misused. Identity verification is not the > solution to all spam problems, it is just the one that is easiest to address > with standards.) The abuse might be coming via Gmail's authenticated identifiers, or it might be coming from an ESP's authenticated identifiers. It's still the same spammer (or compromised account) in both cases. Why would we not want a standard that can attribute the abuse to the gmail.com identity? Just because the domain is used by normal users? > On the specifics of your proposal, I am unclear what types of "intent" you > would put into a client profile. Something along the lines of: This is the rfc5322.from, verified by X, expected volume/patterns, expected nature/category(ies) of content, recipients are confirmed opt-in, supported feedback mechanisms, has one-click-unsubscribe, etc. Basically all of the things that are discussed when giving deliverability guidance to someone building a new email program, but more tangible and useful for all parties. But it might depend on the use case. Such as indirect mail, which is what you're getting at with Stream-Info, I think. Jesse___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Solving DMARC damage with User quarantine and Steram-Info tag
Thank you Jesse for your comments. You are focusing on the ESP problem, which I had not given much thought. ESP messages My approach to ESP traffic is simple. I assume that the ESP has authorized the account indicated by the From address, so I don't worry about Sender Authentication as long as the message passes SPF based on the ESP domain. DMARC is about identity verification, and I am counting on the ESP to ensure that identity verification. ESPs develop a reputation with me based on their ability to vet their clients appropriately. ConstantContact seems to be mostly free of malicious content, so previously-unseen domains are delivered as long as they pass content filtering. SendGrid has not done so well. Previously-unseen domains are delivered to quarantine until I can vet them individually. One ESP has such a high rate of garbage that I have blocked them completely, but that is rare. Hopefully your organization is one that vets its clients pretty well. I tend to assume that the most sophisticated evaluators are doing something similar, but apparently not, or your organization would not be stressing over how to handle the DMARC-affected clients. (Right now my biggest spam problem comes from Gmail.com accounts that are verifiably identified but being misused. Identity verification is not the solution to all spam problems, it is just the one that is easiest to address with standards.) Mailbox provider accounts and ESP accounts are reminders how overwhelming it is to attempt a reputation system based on every sender. The set of all identifiers is nearly infinite. But I am trying nonetheless. On the specifics of your proposal, I am unclear what types of "intent" you would put into a client profile. Forwarded Messages I differ from most of the group because I believe the problem with forwarded messages needs to be handled between the forwarder and the evaluator, not the originator. The solution also needs to be based on message stream characteristics. It is inefficient to evaluate every message individually as if similar ones had never been seen before. My Stream-Info idea is most directly comparable to (or competitive with) ARC. ARC is a way for the forwarder to provide information that it hopes the evaluator will use to ignore sender authentication failures caused by changes in transit.The right to forward-with-changes is essentially a privilege escalation, and privilege escalation needs a well-delimited scope (which messages are included) and justification (why are we doing this) as well as trust (I believe you will not abuse your privilege.) The privilege also needs to be granted by the party most likely to reject the message, and that is of course the evaluator, not the originator. The stream and its identifier characteristics are intended to create a mutually-agreed scope. The "operating principles" section is part of the justification for the request: "You can trust me, because I am doing these good things" Those things cannot be verified on a single message, but they can be inferentially validated when all messages in the message stream are consistent with the asserted principles. I don't think ARC provides enough scope definition, does not provide enough justification, and it does not define a message stream. Finally, it lacks a feedback mechanism so it cannot solve the From-munging problem. The Stream-Info data could reasonably include a feedback address, which would also have a formal structure for automated processing. For forwarded traffic, the two feedback types that immediately come to mind are: - Trust granted: You do not need to Mung addresses for this message stream. - Cease and Desist: Our account user2@domain1 does not want messages to be forwarded from your account user1@domain1. Both types of messages would be sent only a few times, and intermittently, not on every message. Doug Foster On Sat, Apr 1, 2023 at 9:04 PM Jesse Thompson wrote: > On Sat, Apr 1, 2023, at 8:04 AM, Douglas Foster wrote: > > For purposes of the following discussion, assume that messages from > known-bad senders and messages with unacceptable content have already been > blocked. The question at hand is how to handle Sender Authentication > failure when a message has no other objectionable characteristics. > > There are three possible states for a message that is unauthenticated but > otherwise unobjectionable: > > 1) Authorized by domain owner but not verifiable due to configuration > errors or omissions by the sender. > > 2) Authorized (implicitly or explicitly) by a single domain member, or > sent for their benefit. Inherently not verifiable with domain-level > validation. Mailing List messages are one example in this category. > > 3) Not authorized by anyone and therefore illegitimate. > > This framework applies to any unauthenticated message, including DMARC > FAIL or NO POLICY, as well as SPF FAIL, SOFTFAIL, PERMERROR, NEUTRAL or > NOPOLICY. > >
Re: [dmarc-ietf] Solving DMARC damage with User quarantine and Steram-Info tag
On Sat, Apr 1, 2023, at 8:04 AM, Douglas Foster wrote: > For purposes of the following discussion, assume that messages from known-bad > senders and messages with unacceptable content have already been blocked. > The question at hand is how to handle Sender Authentication failure when a > message has no other objectionable characteristics. > > There are three possible states for a message that is unauthenticated but > otherwise unobjectionable: > > 1) Authorized by domain owner but not verifiable due to configuration errors > or omissions by the sender. > > 2) Authorized (implicitly or explicitly) by a single domain member, or sent > for their benefit. Inherently not verifiable with domain-level validation. > Mailing List messages are one example in this category. > > 3) Not authorized by anyone and therefore illegitimate. > > This framework applies to any unauthenticated message, including DMARC FAIL > or NO POLICY, as well as SPF FAIL, SOFTFAIL, PERMERROR, NEUTRAL or NOPOLICY. > > Category 1 and 2 are (by assumption) legitimate messages, but without > authentication they are indistinguishable from Category 3 illegitimate > messages. > > A DMARC policy of p=reject says that there will be no Category 1 messages. > Even when true, it does not resolve the ambiguity between Category 2 and > Category 3. The only way to resolve ambiguity is with more information. One > important aspect of this question is whether the user wants the message. > > I have two approaches for handling these unauthenticated messages. > - Relaxed mode: Deliver the message to the user, then perform an in-depth > review after the fact. > - Strict mode: Deliver the message to system quarantine, then review before > releasing to the user. > > System quarantine is used because: > - I understand how to view and interpret the message headers. > - The quarantine review tool can present the message in a safe-mode view > - My user-mode quarantine review tools do not provide the user with enough > information to make an intelligent decision. > > This approach works well for me, but it does not work for Big Tech because it > requires too much labor. Instead, the work needs to be distributed by > sending "Strict Mode" messages to user quarantine. This requires a creation > of user quarantine wizards that help the user make an intelligent decision > and automate the creation of disposition rules to affect future messages. > > With any review, the goal is to characterize a message stream of which the > current message is an example. In some cases, it may be unclear how to > convert individually approved messages into a message stream definition. > Big Tech is likely to be pretty good at this, but their inference engines > could be assisted by information provided from the message source, using a > URI header like this I have been thinking lately of an intent-based model that seems similar to what you describe. What I am referring to as intents are what you are referring to as operating policies. The customer of an ESP (the author) wants to do X, Y, Z. That is their intent, expressed in good faith. Presumably. The ESP offers guidance on deliverability practices to help the customer be successful with their objectives. A common agreement between the customer and the ESP can be established. The ESP wants to enable the customer to do what they stated, but cannot guarantee that the customer might stray from their intent or be lying. What actually happens in practice can be validated. Stray from intent can be measured. In theory. Ultimately, the ISP decides whether to trust the mail. Currently, the customer needs to warm up their reputation because the ISP has no idea who the customer is and what their intent is. They are protecting themselves from the risk that the customer might suddenly stray from their predictable flow of harmless mail. If the customer does something the ISP does not like, the ISP might decide to block the ESP's shared IP space, affecting other customers of the ESP (causing those other customers to seek solace on the ever-depleting IPv4 dedicated IP address space) So, I was thinking of a mechanism where the customer (indexed by their authenticated identifier) could publish their intent, the ESP can publish what it thinks the customer's intent is, and maybe also publish its measurement about the customer's adherence to/deviance from their stated intent (which I acknowledge is a potential privacy issue). The ISP can do their own measurements of the inbound mail against the intents that have been published, and make a determination based on that. Ideally, this transparent model would reduce the need for the ISP to punish the ESP for assuming [incorrectly] the good faith (or adherence to best practices) of a customer, while also giving the ISP information it needs to react quickly when bad things happen. Customers may rely less on warming up their
[dmarc-ietf] Solving DMARC damage with User quarantine and Steram-Info tag
For purposes of the following discussion, assume that messages from known-bad senders and messages with unacceptable content have already been blocked. The question at hand is how to handle Sender Authentication failure when a message has no other objectionable characteristics. There are three possible states for a message that is unauthenticated but otherwise unobjectionable: 1) Authorized by domain owner but not verifiable due to configuration errors or omissions by the sender. 2) Authorized (implicitly or explicitly) by a single domain member, or sent for their benefit. Inherently not verifiable with domain-level validation. Mailing List messages are one example in this category. 3) Not authorized by anyone and therefore illegitimate. This framework applies to any unauthenticated message, including DMARC FAIL or NO POLICY, as well as SPF FAIL, SOFTFAIL, PERMERROR, NEUTRAL or NOPOLICY. Category 1 and 2 are (by assumption) legitimate messages, but without authentication they are indistinguishable from Category 3 illegitimate messages. A DMARC policy of p=reject says that there will be no Category 1 messages. Even when true, it does not resolve the ambiguity between Category 2 and Category 3. The only way to resolve ambiguity is with more information. One important aspect of this question is whether the user wants the message. I have two approaches for handling these unauthenticated messages. - Relaxed mode: Deliver the message to the user, then perform an in-depth review after the fact. - Strict mode: Deliver the message to system quarantine, then review before releasing to the user. System quarantine is used because: - I understand how to view and interpret the message headers. - The quarantine review tool can present the message in a safe-mode view - My user-mode quarantine review tools do not provide the user with enough information to make an intelligent decision. This approach works well for me, but it does not work for Big Tech because it requires too much labor. Instead, the work needs to be distributed by sending "Strict Mode" messages to user quarantine. This requires a creation of user quarantine wizards that help the user make an intelligent decision and automate the creation of disposition rules to affect future messages. With any review, the goal is to characterize a message stream of which the current message is an example. In some cases, it may be unclear how to convert individually approved messages into a message stream definition. Big Tech is likely to be pretty good at this, but their inference engines could be assisted by information provided from the message source, using a URI header like this Stream-Info: http://dmarc.listpracties.ietf.org. Below are two examples of what information could be provided in a stream info declaration. A formal specification would be needed but is not provided. For the IETF Mailing List stream, those characteristics are: - The message stream type is: Mailing List - Identifier information: - SMTP MailFrom is always dmarc-boun...@ietf.org and produces SPF PASS - Messages are signed by ietf.org - HELO domain is ietf.org and can be forward-confirmed - Reverse DNS domain is ietf.org and can be forward-confirmed - ARC Sets are not added to forwarded messages. - Operating Policies: - Every post is verified to the subscriber with DMARC or challenge-response verification - From header is rewritten for messages with DMARC p=reject - Incoming messages are converted to text mode, and a footer is added, so prior signatures are invalidated For a simple user-to-user forward, the characteristics could be: - The message stream type is: User Forward - Identifier information: - Previous TO domain was example.com - SMTP MailFrom is SRS encoded version of the original sender - ARC Sets are added to forwarded messages - Operating policies: - Messages are scanned for malware on a best-effort basis. - Content is not modified, so prior signatures are preserved, but not all messages will have prior signatures Doug Foster ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
