Re: [dmarc-ietf] ARC vs p=quarantine
On 2020-12-20 23:07, Michael Thomas wrote: On 12/20/20 2:01 PM, Benny Pedersen wrote: hopefully maillists stops dkim signing, its the incorrect place to solve breaking dkim Sorry, ARC is warmed over DKIM, and an experiment. DKIM is a full internet standard and expressly intended for lists, etc to resign if they broke the original DKIM signature. We have always had the ability to do reputation checks regardless of ARC. I'm not sure when this wg lost sight of that. only original senders should dkim sign, rest should only arc sign, i dont have to agre on anyhing other then that, if maillists dkim sign thay try to steel the original dkim private key without succes, and there is possible a solotion to dmarc adsp handling this break seeing eitf do 3 dkim sign just to be sure it does not work ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC vs p=quarantine
On 12/20/20 2:01 PM, Benny Pedersen wrote: hopefully maillists stops dkim signing, its the incorrect place to solve breaking dkim Sorry, ARC is warmed over DKIM, and an experiment. DKIM is a full internet standard and expressly intended for lists, etc to resign if they broke the original DKIM signature. We have always had the ability to do reputation checks regardless of ARC. I'm not sure when this wg lost sight of that. Mike ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC vs p=quarantine
On 2020-12-20 19:13, John R Levine wrote: On Sun, 20 Dec 2020, Alessandro Vesely wrote: question is who steps up to provide such shared lists. Dnswl.org counts about 25K domains. I suppose one might try them but I expect most of them are not sending forwarded mail. only sending to maillists here that breaks dkim and do not add arc before breaking dkim, world of 2020 cant be better :=) I've finally gotten around to doing ARC checks in my SMTP daemon so I can see who's adding ARC seals. hopefully maillists stops dkim signing, its the incorrect place to solve breaking dkim now that nearly all maillists i am on have showed what not to do, its hopefully solved soon ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] p=quarantine
Like any security problem, we need to minimize false positives (desired mail being blocked) and false negatives (unwanted or malicious mail being allowed). ARC will hopefully address the false positives, but the false negative issue remains. The situation does not seem hopeless, but the topic does appear to be underdeveloped. Here are some observations: SPF PASS means the message was received directly from the stated domain, but it does not indicate whether or not the stated domain was the originator, since the SMTP address may have been rewritten. Similarly, SPF FAIL indicates that the message was not received directly from the stated domain, but it cannot distinguish between a message that originated from an unauthorized source and a message that originated from an authorized source but was then forwarded without SMTP rewrite.The FAIL could also be the result of a DNS configuration error, such as a domain that changed hosting services without changing their SPF policy record. The issues with failed DKIM signatures and From rewrite are similar. A forwarded message may have: - no address rewrite causing SPF FAIL but no masking of the originator address, - transparent address rewrite using SRS or ARC, or - non-transparent replacement of prior SMTP and/or From addresses, without SRS or ARC clues being included (as this list). Consequently, the only reliable way to detect an untrusted source behind a forwarder is to evaluate the entire message header chain. Blacklisting --- For purposes of filtering unwanted messages, verifiable header data is not required. (If someone wants to spoof an untrusted sender, I am happy to consider that spoofer untrusted also.) The Received chain can be checked for IP addresses and DNS names with negative reputation. Similarly, any Received-SPF, Authentication-Results, ARC-Authenticated-Results, Authenticated-As or similar headers can be checked for email domain names with negative reputation. All of this can and should be done regardless of the SPF and DMARC status, because SPF and DMARC are designed around direct mail flows, and SPF and DMARC pass can be achieved by pretending to be a direct mail flow. An additional test is to count the number of organizations that handled the message along the delivery path.First, consolidate out the Received headers with private IPs or loopback IPs, then (probably) drop any messages transferred over LMTP, and any transfers where the ReverseDNS and HELO domains are unchanged in the handoff. What should be left is a small number of entries where the FROM information indicates the IP and hostnames of the sending organization and the HELO name should be an MX of the receiving organization. (SPF checks and Forward-confirmed DNS checks can then be performed on this data.) For direct messages, I assume that the maximum number of organization boundaries should be three: - Cloud-based SMTP submitting client to mailstore organization, - mailstore organization to cloud-based outbound filtering service, - then outbound filtering service to destination domain. Additionally, the cloud-based outbound filtering services are relatively few and well known, which should simplify determining whether an intermediate organization is a filtering service or a forwarding service. It seems axiomatic that a forwarder will have an unreliable reputation with recipients. If the forwarder blocks a message, the recipient system will not directly know that it was blocked, whether the blocked message was wanted or unwanted. But if the forwarder allows a message that the recipient does not want, the forwarder takes a hit on its reputation. An automated forwarding service has an incentive to avoid false positives, so it is almost certain to have a spam filtering policy which is weaker than the final recipient system.Rather than blaming the forwarding service for unwanted messages getting through, the evaluator should look at the entire received chain. Whitelisting --- It is much riskier to perform whitelisting based on the header data, because one must allow for the possibility that a nation-state attacker will construct a convincing but fraudulent header chain, if they perceive that doing so will succeed. But I cannot imagine whitelisting a message from a random forwarder based on header data alone. I would only do that if the forwarding service, message originator, and forwarding path were well understood from external sources. In that case, a message from a well-identified forwarding service with a sufficiently-identified message originator might be a candidate for whitelisting. But those situations seem likely to be rare. Conclusion --- The overall conclusion is that if a message's only negative indicator is an authentication failure, the best practice would be to send it to administrative quarantine for local policies to be tailored to the situation. It seems foolish to block a messag
Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports
On Fri 18/Dec/2020 21:05:43 +0100 John R Levine wrote: [ failure reports leak PII including forwarded recipients ] Are failure reports about forwarded messages still useful? If not so much, perhaps we could deplore them. There's no mechanical way to tell whether a message has been forwarded as opposed to bcc or a mailing list or a local redistribution list or whatever. Given how few sites send failure messages, and that we all seem able to manage our DMARC setups without them, I don't think they're worth a lot of effort. Hence my suggestion for simplified advice. Keeping the target of forwarded messages private needs to be addressed at emailcore as well, though. Regular bounces leak the same info. That seems like a great way to destroy mailing lists by not telling them which recipients are bouncing. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC vs p=quarantine
On Sun, 20 Dec 2020, Alessandro Vesely wrote: question is who steps up to provide such shared lists. Dnswl.org counts about 25K domains. I suppose one might try them but I expect most of them are not sending forwarded mail. I've finally gotten around to doing ARC checks in my SMTP daemon so I can see who's adding ARC seals. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] p=quarantine
On Fri, Dec 18, 2020 at 4:55 PM Michael Thomas wrote: > > On 12/15/20 8:01 AM, Todd Herr wrote: > > > I'm not sure there's anything actionable about DMARC's policy values. > > you mean p=quarantine, or p=* in general? > Depending on the level of sophistication of a receiving email system, a given email message can have dozens of signals (or data points) associated with it, of which the relevant DMARC policy record, if it exists, is one. Those signals can all be actionable, individually or collectively, or ignored entirely, in that receiving system's decision to accept or reject the message, and if it accepts it, the decision of where to place that message. If an applicable DMARC policy record exists for the RFC5322.From domain in a message, the receiver can: - Perform the necessary authentication checks for DMARC validation, and use those validation results and the p= value as the sole or primary determining factor in how to handle the message, strictly applying the p= value in cases where it's not 'none' and validation checks fail - Perform the necessary authentication checks for DMARC validation, and use those validation results and the p= value as the sole or primary determining factor in how to handle the message, loosely applying the p= value in cases where it's not 'none' and validation checks fail (e.g., placing the message in the spam folder even if p=reject is specified in the policy record) - Perform the necessary authentication checks for DMARC validation, and use those validation results and the p= value as one data point in a larger data set in how to handle the message - Ignore the DMARC policy record entirely > Obviously indirect mail flows, such as mailing lists and forwarding, > complicate matters greatly here, as the handling by the intermediary > host(s) can and will lead to a higher percentage of authentication > failures. The community has attempted to mitigate this problem; > RFC5322.From header rewriting, RFC5321.From header rewriting (e.g., SRS), > and ARC are among the attempts put forth so far, but none have been deemed > The Solution(tm) yet. In my opinion, ARC has promise, because if a message > reaches me as a receiver or even intermediary and fails the authentication > checks I perform, ARC header sets in the message can tell me whether or not > such checks passed at previous hops *if I trust the entities that inserted > those ARC header sets*. In an earlier thread, I floated an idea about ARC > sealer reputation, but it didn't draw much response, so I'll float it here > again in the hopes that it does. > > We've always been able to check the reputation of lists that resign the > message. The reputation is the previously (un)solved problem. > > > Lists are a specific instance of the more general case of indirect mail flows. Any intermediate host can ARC seal and ARC-sign (a term I use as distinct from re-sign) a message, an act that is meant to capture the results of authentication checks done when it reached the intermediary. Whether or not the receiver trusts those results (especially those results that claim that authentication checks passed at the intermediary) when the message reaches the receiver depends on the intermediary's reputation for being a truthful sealer and signer, meaning whether or not it has established a history of capturing authentication results that are true and accurate. Since the receiver typically can't perform the same checks under the same conditions that existed when the intermediary performed them (if it could, we wouldn't need something like ARC) then the receiver has to decide if the message is consistent with messages it's previously seen through direct mail flows using that same authenticated identity that was captured by the intermediary in the ARC header set. If the indirect mail flow looks like the direct mail flow, then the sealer is showing evidence that it can be trusted, and so the indirect mail flow can receive the same treatment by the receiver that it would give to the direct mail flow associated with the authenticated identity. If the indirect mail flow looks different than the direct mail flow, then the receiver can either decide to not trust the sealer and so treat the indirect mail flow as unauthenticated, or perhaps it can dig into matters further to see why the difference exists. A mailing list, for example, that has subscribers whose domain is a consumer mailbox provider might just show an indirect mail flow for that domain to the receiver that has a substantially better overall reputation than the direct mail flow for that domain to the receiver; rather than letting this difference impact the level of trust in its sealing reputation that a receiver would assign to the list, it may very well have to put in an override to its system for tracking sealer trust. -- *Todd Herr* | Sr. Technical Program Manager *e:* todd.h...@valimail.com *p:* 703.220.4153 This email and all
Re: [dmarc-ietf] Ticket #55 - Clarify legal and privacy implications of failure reports
On Fri 18/Dec/2020 21:05:43 +0100 John R Levine wrote: Info which is encoded in such a way that only the sender can understand rises no PII concern, IMHO. A sender could cache sent messages and devise how to encode the corresponding filenames in DKIM selectors. Reporting just the failed signature would leak the whole message by reference. So what? Now he knows which forwarded recipients are talking with his users. Are failure reports about forwarded messages still useful? If not so much, perhaps we could deplore them. Keeping the target of forwarded messages private needs to be addressed at emailcore as well, though. Regular bounces leak the same info. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] ARC vs p=quarantine
On Sat 19/Dec/2020 21:50:34 +0100 Dotzero wrote: On Sat, Dec 19, 2020 at 2:50 PM John Levine wrote: In article <1e61f7c4-c6d2-5dab-dfc7-f1fd740e1...@tana.it> you write: Now my tiny MX stores 115,225 domains total. And I have no idea how I could add a trust-ARC-seals boolean field to each domain record. >> You wouldn't. Only a small fraction of those domains send enough forwarded mail to be worth worrying about. We know we need some sort of shared list of plausible forwarders but I would be amazed if it were anything like 115K domains. > So the need for a shared list has been expressed a number of times. The real question is who steps up to provide such shared lists. Dnswl.org counts about 25K domains. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Messages from the dmarc list for the week ending Sun Dec 20 06:00:05 2020
Count| Bytes | Who ++--- 10 (23.3%) | 61316 (13.9%) | Alessandro Vesely 6 (14.0%) | 29727 ( 6.7%) | John Levine 5 (11.6%) | 95589 (21.7%) | Douglas Foster 5 (11.6%) | 34737 ( 7.9%) | Michael Thomas 3 ( 7.0%) | 82453 (18.7%) | Laura Atkins 3 ( 7.0%) | 29435 ( 6.7%) | Dotzero 3 ( 7.0%) | 10855 ( 2.5%) | Dave Crocker 2 ( 4.7%) | 33759 ( 7.7%) | Todd Herr 2 ( 4.7%) | 24000 ( 5.4%) | Brotman, Alex 1 ( 2.3%) | 13894 ( 3.1%) | Seth Blank 1 ( 2.3%) | 10897 ( 2.5%) | Henning Krause 1 ( 2.3%) | 8148 ( 1.8%) | Tim Wicinski 1 ( 2.3%) | 6362 ( 1.4%) | Dave Crocker ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
