Re: [dmarc-ietf] Another p=reject text proposal
On Fri, Jul 7, 2023 at 6:14 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Malicious impersonation creates a need for authentication. If the list > makes changes that disable the originator's authentication, then it is the > list's problem to find a way to convince the recipient that the message is > not a malicious impersonation. ARC and Munging together are the best > available way to do so, because no other options are on the table. > I continue to disagree with this line of thinking. Lists have been behaving a particular way, with important operational benefits to users (unrelated to authentication), for a very long time. That they should suddenly be told by senders that the Internet works a different way starting now and those behaviors are wrong and must be fixed, to me, defies reason. If you want to blame someone for the list problem, blame the criminals. > Here, we agree. -MSK, participating ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
On Fri, Jul 7, 2023 at 6:35 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Consequently, the problem remains: How does an evaluator distinguish > between a legitimate list and a malicious attack? > If we had a reliable answer to that, this would've been over ages ago. Unfortunately, any mechanism we create for lists to distinguish their traffic can be trivially co-opted by bad actors. > My answer: Lists need to use From munging to avoid DMARC FAIL, and hope > that sophisticated evaluators will use ARC data to un-mung before delivery. > Someone else asserted that lists have been dealing with DMARC damage by, among other things, rewriting From fields for some years now. Let me pose a couple of questions to list operators and developers and those friendly to those audiences: 1) Are list operators and developers tolerating this situation, temporarily, because they think this crew is going to come up with a less disruptive permanent solution to which they expect to migrate one day? 2) If not, have they resigned themselves to such things as From rewriting as the way of the future? 3) If so, how big (or small) is the set of DMARC accommodations on which they seem to be converging? -MSK, participating ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
Scott Kitterman writes: > You can equally argue that these receivers are merely following the > policy advice provided by the sending domain (it has reject right in > the name) and this problem is entirely generated by sender's > inappropriate use of p=reject. True, thats why the proposed text also says you SHOULD NOT put p=reject... :-) > I don't think engineering the location where the blame lands is the > right place to focus. I've done plenty of blame avoidance > engineering in my day, but I don't think it's what the IETF should > be doing. It would be much better when people would really remember that having valid or not valid DMARC/DKIM/SPF for email does not tell anything whether the email is bad/spam/unwanted. Regardless whether the DMARC/DKIM/SPF is valid you always need to use other methods to filter emails, so as you need to do that anyways while receiving emails, there is no problems of using same things also for p=reject messages. You can use the failed dmarc with p=reject as one of the inputs to feed your actual email filtering system, the dmarc p=reject SHOULD NOT BE your only email filtering system. -- kivi...@iki.fi ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
On July 8, 2023 6:16:46 PM UTC, Tero Kivinen wrote: >Brotman, Alex writes: >> I suspect the portion that instructs receivers to not act solely on >> p=reject may be ignored by a fair set of receivers. I'm not >> necessarily opposed to the language below, just that it seems odd to >> create language that we know will be ignored. > >If receivers ignore that, then at least we can complain to them and >say that you should not do that, as the RFC says you should use other >information too if they want to get important forwarded emails >through. For example we in iki.fi have been regularly been helping >people with their broken spf etc records which break forwarding, and >several times we have actually managed to explain the situation and >they have change their settings. Quite often those people simply >follow whatever some consultant etc suggested, and they did not >understood at all that they at the same time broke other things. > >Quite often they do want to reduce the amoung of support calls, and if >they get support calls every time some forwarded email from mailing >list or from forwarding gets rejected, they most likely will notice >that and fix their setup. > >> Additionally, I find it odd that we won't tell forwarders how to >> munge messages to avoid this situation, but we will tell receivers >> how to avoid this situation. > >There is no good way for forwards to mungle message in such way that >return path/DKIM/user expectations stays intact. I myself for example >find the From address mangling done by this mailing list really >annoying as I need to use extra time to parse the =40 addresses to >find out domain name of the sender. > >For mailing list this is just annoying but you can do that, but for >regular forwarding you can't do that as you want to keep the DKIM >signature intact. > >And this problem is not generated by forwarders, it is generated by >the receivers who only use DMARC and no other information while >rejecting emails. So there is no point of asking forwarders to fix >things that was broken by DMARC... You can equally argue that these receivers are merely following the policy advice provided by the sending domain (it has reject right in the name) and this problem is entirely generated by sender's inappropriate use of p=reject. I don't think engineering the location where the blame lands is the right place to focus. I've done plenty of blame avoidance engineering in my day, but I don't think it's what the IETF should be doing. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
Brotman, Alex writes: > I suspect the portion that instructs receivers to not act solely on > p=reject may be ignored by a fair set of receivers. I'm not > necessarily opposed to the language below, just that it seems odd to > create language that we know will be ignored. If receivers ignore that, then at least we can complain to them and say that you should not do that, as the RFC says you should use other information too if they want to get important forwarded emails through. For example we in iki.fi have been regularly been helping people with their broken spf etc records which break forwarding, and several times we have actually managed to explain the situation and they have change their settings. Quite often those people simply follow whatever some consultant etc suggested, and they did not understood at all that they at the same time broke other things. Quite often they do want to reduce the amoung of support calls, and if they get support calls every time some forwarded email from mailing list or from forwarding gets rejected, they most likely will notice that and fix their setup. > Additionally, I find it odd that we won't tell forwarders how to > munge messages to avoid this situation, but we will tell receivers > how to avoid this situation. There is no good way for forwards to mungle message in such way that return path/DKIM/user expectations stays intact. I myself for example find the From address mangling done by this mailing list really annoying as I need to use extra time to parse the =40 addresses to find out domain name of the sender. For mailing list this is just annoying but you can do that, but for regular forwarding you can't do that as you want to keep the DKIM signature intact. And this problem is not generated by forwarders, it is generated by the receivers who only use DMARC and no other information while rejecting emails. So there is no point of asking forwarders to fix things that was broken by DMARC... -- kivi...@iki.fi ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
It appears that Richard Clayton said: >They then moved on to just using random identities from the same domain >as the recipient. This led a great many Yahoo users to believe that a >great many other Yahoo users had been compromised, leading to a >significant loss of faith in the integrity of the platform. We get that, but why did they have to inflict DMARC policy on the world rather than just adjusting their own mail software to filter out incoming mail with Yahoo return addresses from other places? I assume the answer was that the DMARC code was already written so it was cheaper. >strong, mailing lists (and other forwarders that mangle email) have been >coping with p=reject for nearly a decade -- so that trying >(ineffectually in practice) to make their lives easier at this point is >a snare and a delusion. There seem to be a fair number of people working on ARC who disagree. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
*Note: The following is a general rule of thumb for me.* From my functional specification protocol language coding standpoint: MUST --> NO OPTION. Technically enabled with no switch to disable. SHOULD -> OPTIONAL, Default is ON, enabled MAY --> OPTIONAL, Default is ON or OFF depending on implementation With the special RFC documentation format designed/written for a very wide audience from managers, system admins, coders, engineers, etc, it offers semantics with lower and upper case guidelines. sometimes purposely ambiguous (to keep it open ended) and in the IETF RFC, we have used the UPPER CASE language as a way to create code especially with standard track items. Those who choose to ignore the UPPER CASE interop advice often risk having the proverbial book thrown at them. With lower case semantics, this has been my overall implementation methods: may, should --> may be implemented as options as with upper case must --> may be implemented and enabled with hidden option to disable. -- HLS On 7/8/2023 12:49 PM, Richard Clayton wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message, Murray S. Kucherawy writes Some of my IETF mentors (ahem) taught me some stuff about the use of SHOULD [NOT] that have stuck with me, and I'm going to pressure test this against that advice.� Let's see how this goes.� :-) "SHOULD" leaves the implementer with a choice.� You really ought to do what it says in the general case, but there might be circumstances where you could deviate from that advice, with some possible effect on interoperability. I noted that one of the earlier messages which endorsed MUST NOT said that of course some people might know better -- which is what I always understood SHOULD NOT was for ! � If you do that, it is expected that you fully understand the possible impact you're about to have on the Internet before proceeding.� To that end, we like the use of SHOULD [NOT] to be accompanied by some prose explaining when one might deviate in this manner, such as an example of when it might be okay to do so. not so much "OK" as "necessary". Yahoo's original statement (I'm prepared to name names rather than pussyfoot around this) on the deployment of p=reject is discussed here: https://wordtothewise.com/2014/04/yahoo-statement-dmarc-policy/ and I believe it is widely understood that it was particularly deployed to counter the "address book spammers" of the time. These bad guys originally persuaded people to open their email by forging it to appear to come from their friends (having compromised relevant address books). They then moved on to just using random identities from the same domain as the recipient. This led a great many Yahoo users to believe that a great many other Yahoo users had been compromised, leading to a significant loss of faith in the integrity of the platform. Does anyone have such an example in mind that could be included here?� Specifically: Can we describe a scenario where (a) a sender publishes p=reject (b) with users that post to lists (c) that the community at large would be willing to accept/tolerate? So the example you seek might be phrased along the lines of when failing to set p=reject means that significant quantities of forged email will be delivered and this will cause damage. Personally (not a $DAYJOB$ opinion) I think SHOULD NOT is still too strong, mailing lists (and other forwarders that mangle email) have been coping with p=reject for nearly a decade -- so that trying (ineffectually in practice) to make their lives easier at this point is a snare and a delusion. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -- Hector Santos, https://santronics.com https://winserver.com ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Murray S. Kucherawy writes >Some of my IETF mentors (ahem) taught me some stuff about the use >of SHOULD [NOT] that have stuck with me, and I'm going to pressure >test this against that advice. Let's see how this goes. :-) > >"SHOULD" leaves the implementer with a choice. You really ought to >do what it says in the general case, but there might be >circumstances where you could deviate from that advice, with some >possible effect on interoperability. I noted that one of the earlier messages which endorsed MUST NOT said that of course some people might know better -- which is what I always understood SHOULD NOT was for ! > If you do that, it is >expected that you fully understand the possible impact you're about >to have on the Internet before proceeding. To that end, we like >the use of SHOULD [NOT] to be accompanied by some prose explaining >when one might deviate in this manner, such as an example of when >it might be okay to do so. not so much "OK" as "necessary". Yahoo's original statement (I'm prepared to name names rather than pussyfoot around this) on the deployment of p=reject is discussed here: https://wordtothewise.com/2014/04/yahoo-statement-dmarc-policy/ and I believe it is widely understood that it was particularly deployed to counter the "address book spammers" of the time. These bad guys originally persuaded people to open their email by forging it to appear to come from their friends (having compromised relevant address books). They then moved on to just using random identities from the same domain as the recipient. This led a great many Yahoo users to believe that a great many other Yahoo users had been compromised, leading to a significant loss of faith in the integrity of the platform. >Does anyone have such an example in mind that could be included >here? Specifically: Can we describe a scenario where (a) a sender >publishes p=reject (b) with users that post to lists (c) that the >community at large would be willing to accept/tolerate? So the example you seek might be phrased along the lines of when failing to set p=reject means that significant quantities of forged email will be delivered and this will cause damage. Personally (not a $DAYJOB$ opinion) I think SHOULD NOT is still too strong, mailing lists (and other forwarders that mangle email) have been coping with p=reject for nearly a decade -- so that trying (ineffectually in practice) to make their lives easier at this point is a snare and a delusion. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -BEGIN PGP SIGNATURE- Version: PGPsdk version 1.7.1 iQA/AwUBZKmTft2nQQHFxEViEQJ4zACfUiVCRzGjK68phKi73kl0kg0CKnAAnjAB ft3PPkV73wIPjvYs7tCjrCsm =EUgy -END PGP SIGNATURE- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
On Sat 08/Jul/2023 02:44:19 +0200 Murray S. Kucherawy wrote: On Thu, Jul 6, 2023 at 7:55 AM Barry Leiba wrote: It is therefore critical that domains that host users who might post messages to mailing lists SHOULD NOT publish p=reject. Domains that choose to publish p=reject SHOULD implement policies that their users not post to Internet mailing lists. Some of my IETF mentors (ahem) taught me some stuff about the use of SHOULD [NOT] that have stuck with me, and I'm going to pressure test this against that advice. Let's see how this goes. :-) "SHOULD" leaves the implementer with a choice. You really ought to do what it says in the general case, but there might be circumstances where you could deviate from that advice, with some possible effect on interoperability. If you do that, it is expected that you fully understand the possible impact you're about to have on the Internet before proceeding. To that end, we like the use of SHOULD [NOT] to be accompanied by some prose explaining when one might deviate in this manner, such as an example of when it might be okay to do so. Does anyone have such an example in mind that could be included here? Specifically: Can we describe a scenario where (a) a sender publishes p=reject (b) with users that post to lists (c) that the community at large would be willing to accept/tolerate? The preceding, non-indented paragraph seems to devise a tolerance boundary in the future: Domains that have general users who send routine email are particularly likely to create interoperability issues if they publish p=reject. For example, domains that serve as mailbox hosts and give out email addresses to the general public are best advised to delay adoption of p=reject until the authentication ecosystem becomes more mature and deliverability issues are better resolved. /More/ mature and /better/ resolved might still be obscure. For the time being, IME, the ecosystem is mature enough to resolve the mailing list interoperability issues by From: munging. I agree it might become more mature and find out better ways. Yet, the current level might seem enough to permit p=reject where it is necessary —unless there are situations (unknown to me) where the damage is still serious or substantial. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
