Re: [dmarc-ietf] WGLC contentious topics (I'm in the rough and I know it) in draft-ietf-dmarc-dmarcbis-30
Le 01/04/2024 à 03:36, Seth Blank a écrit : ^^ > In order from most to least contentious: > > 1. 8.6. Interoperability Considerations > > "It is therefore critical that domains that host users who might post > messages to mailing lists SHOULD NOT publish p=reject." > […] Hopefully the date over here is significant. The compromise about SHOULD NOT was hard enough to achieve, that no reasonable person would really want to reopen it in WGLC. April foolsy, Baptiste ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Dmarcbis way forward
Hi, Le 23/10/2023 à 19:59, Alessandro Vesely a écrit : My opinion is that Barry's text is good as is. As far as delimiting a SHOULD NOT with another SHOULD is legit, this sentence sounds clear to me: 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. The exceptions to the latter SHOULD are rather obvious. Do we really need to formally specify domain policing? I for one would be interested in hearing what you believe those exceptions are. When reading your aggressive next paragraph, I'm lead to think that in your view, "technologies dating from the 80s deserve no respect" is reason enough to break both SHOULDs. There may be rough consensus for a good faith SHOULD, but definitely not for overt disrespect of interoperability in the name of some brave new "today's reality". Cheers, Baptiste My perception is that Section 8.6 puts the issue in very clear terms. It is even overly clearly and thoroughly explained for average readers. Only IETF purists longing for email as it was in the 80s consider it important to point out how DMARC is unjustly oppressing email forwarding, including mailing lists. The rest of the world just use it as needed. In today's reality, we should just move forward, and devise further protocols to fix forwarding after DMARCbis is out. By contrast, the last paragraph of Section 7.6 contradict this point and should be removed. Best Ale ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Eliminating From Munging from this list
Hi, Le 19/07/2023 à 19:38, Alessandro Vesely a écrit : > > Oops, I had in mind that lists modify messages. Some of them don't, > that way they don't need From: munging. It is quite common too. > > Let me reword the question: Are there lists that modify messages and > don't munge From:? What exactly is this question achieving? It looks to me, what you are trying to assess is the level of resignation, after 10 years of bullying, to a poor workaround that we know list users hate (because it breaks the semantics of the conversation). Cynical at best. We also know this workaround doesn't help DMARC in the long run, as it undermines the significance of the From header. Which is why this group never endorsed it. So where do we go from here? Cheers, Baptiste ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Eliminating From Munging from this list
Hi, Le 17/07/2023 à 03:50, Emanuel Schorsch a écrit : > > - By default FromMunging remains the practice without special > information. > - MailingLists add ARC Headers and an additional header for what the > unmunged FromHeader was > […] > This gives the information needed to evaluators to undo the fromMunging on > their end. Well, call me a pessimist if you will, but I parse this as: generalize FromMunging now in the hope for a future, "potential", solution. It looks like a trap: if FromMunging gets even more normalized, evaluators will have even less incentive to work towards an actual fix. The best outcome I see is that power users will be able to undo the munging client-side with a MUA-plugin. Which is nice, but only solves the problem for a very small part of the community. Cheers, Baptiste ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Eliminating From Munging from this list
Hi, Le 15/07/2023 à 12:22, Douglas Foster a écrit : [...] Track 2: Exception Request [...] Track 2 benefits: [...] - Elimination of From munging is potentially available to all participants, even those from p=reject domains This important word here is "potentially". In practice, only an insignificant part of this potential can be achieved, because your plan heavily relies on non-automatable human work, and on end users being able to weight into their providers' policies. Thus for all practical purposes, "conditional munging" is equivalent to plain munging. Therefore I propose Track 3: 1) We undo existing munging. 2) We inform end users that, if they do not receive messages from certain senders (especially those senders whose addresses were previously munged), they can regain them by switching their subscription mode to "digests", at least temporarily while their mailbox provider fixes their DMARC handling. 3) Whenever we get bounces, we configure our software to forcibly switch the offending users (I mean the receivers) to "digests". We inform the impacted users that they can try resetting their subscription mode to plain messages after a few months, in case their provider fixed their handling in between. 4) We publicize our rules widely, so mailbox providers know how to avoid inconveniencing their users. Track 3 benefits: - fully automatable - doesn't break the semantics of conversations (digests correctly embed the messages instead of improperly claiming authorship) - gives mailbox providers an incentive to move to a more sophisticated DMARC handling. - doesn't rely on the sending side to fix their practices, as the consensus here seems to be that it will never happen. Cheers, Baptiste ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
Hi, Le 07/07/2023 à 23:58, John R Levine a écrit : > > Why is it up to the recipient systems (the ones that do not care) to > make life easier for lists? Mailing list packages already do lots of > analysis of bounce messages. How about if they fix their bounce > processing to recognize DMARC failures and do something different. Why? Because it's brittle and will only bring them more headaches? At the very least, DMARC would need to use its own 5xy reply code to avoid the need for parsing the reply text… Or simply because they are *not* DMARC participants, and thus have no reason to read this list? Standards usually serve to organize interoperability between participants, not to inflict demands upon unrelated third parties that they knowingly break. That being said, maybe there is some simpler and better advice we can give to mailing list operators who happen to listen: "If messages bounce, first try to forcibly set the digest sending mode for this user. If digests bounce too, then it's not DMARC, unsubscribe as usual". If the mailing list software has a digest mode, implementation is straightforward, and I can see no downsides compared to unsubscribe right from the start. Cheers, Baptiste ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
Hi, Le 08/07/2023 à 20:24, Scott Kitterman a écrit : > > 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. This is not about blame avoidance. Blame avoidance is what happens right now on this very list, with author domains and mail receivers first blaming each other, then colluding to accuse absentee forwarders… This is about avoiding the Tragedy of Commons where everyone waits for the breakage to somehow solve itself (or, more cynically, for the victim to resignate). The standard can help by clearly stating who has to act in which circumstances. A MUST is better than a SHOULD, an it might well be that two SHOULDs are worse than just one. Cheers, Baptiste ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
Hi, Le 07/07/2023 à 21:09, Scott Kitterman a écrit : > Doesn't sieve happen during delivery, after the message has been accepted? > Is so, I don't think it's a useful comparison to make. > > The lack of bounce/rejection messages results in messages that vanish and > undermines the reliability of the email ecosystem. I agree that silent > discard between MTAs is bad and we should not encourage it. Please remember that "silent discard" is already proposed as a delivery option in today's DMARCBis, section 8.3 (I wouldn't have dared to use those words otherwise, I have principles too :-) ). But if it makes people feel better, we can call it "delivery to user-inaccessible system quarantine". We can even add that messages are not to be deleted from said quarantine until the DMARC reports have been sent, so that no message ever just "vanishes". Rejecting at SMTP time also constrains the additional analysis that we say Mail Receiver MUST do before rejecting, so deferred discard is bound to become more common with DMARCBis anyway. Also, maybe time has come to be pragmatic, as DMARC has been causing breakage for 10 years already, all RFCs not withstanding. Bounces are feedback sent to the wrong place, and bring no useful consequences. At best they are ignored (which is just as sinful as not sending them), and in the common worst case, they are misunderstood and break havoc. Feedback to the right place (the author domain) happens through DMARC reports. On the benefit side, suppressing the risk of bounces avoids forcing the mailing list operators to second-guess mail receivers and apply problematic workarounds a priori. Recipients whose mail operator correctly applies additional analysis can thus enjoy an unaltered experience, which provides incentive. And recipients who lose messages because their operator discards them can always elect to receive digests, which are not impacted by DMARC. Cheers, Baptiste ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
Hi, I consider this a step backwards. The MUST requirement on the author domain finally made it clear, after a lost decade, *who* is responsible for solving the breakage of indirect mailflows. Problem solving starts with acknowledging one's responsibilities. This proposal goes back to a muddy shared responsibility between the author domain and the mail receiver. This is the best way to make sure nothing changes, as each waits for the other to act. Mailing lists can expect to suffer for more long years. No wonder the From-munging proponents are rejoicing! If this goes in, at least something has to be done to reduce bounces, such as: — Section 8.3 — ADD The Mail Receiver MUST reject with "silent discard" when rejecting messages with a List-Id header. END That way, each party's choices will mostly impact their own messages. Mailing list operators can then take a step back, undo any ugly workarounds, and let DMARC participants decide between themselves, on a case by case basis, how they solve *their* deliverability problems. Cheers, Baptiste Le 06/07/2023 à 16:55, Barry Leiba a écrit : > I had some off-list discussions with Seth, who was very much against > my original proposed text, and he suggested an alternative > organization that would be more palatable to him. I've attempted to > set that out below. The idea is to remove the normative requirements > about using p=reject from Sections 5.5.6 and 5.8, and instead put a > broader discussion of the issues, along with the normative > requirements, into a new "Interoperability Considerations" section. > This makes it explicitly clear that any MUST/SHOULD stuff with regard > to using and honoring p=reject is an issue of interoperating with > existing Internet email features. I can accept that mechanism also, > and so, below is my attempt at writing that proposal up. > > Barry ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?
Hi, Le 06/04/2023 à 20:05, Dotzero a écrit : > > So Baptiste, what responsibility do you expect these organizations to > undertake? I'm asking this as a serious question, not a rhetorical one. > In all seriousness they are/were focused on addressing their, > potentially existential, problems and not those of others. One might > state that is a very selfish attitude. […] Well, for a start I only expect that everybody recognize who exactly is responsible for the breakage. There seems to not even be a clear agreement inside this list. This group has to make a decision and record it in the standard (and a MUST NOT might well be the way to express it). And yes, selfish organizations might ignore the standard and willingly break interoperability. Then there's nothing we can do. But for those who care about fixing what they break, pointing fingers at the right place is a necessary start. Also, impacted mailing lists can more easily retaliate against the selfish if their bad faith is obvious. Cheers, Baptiste ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?
Hallo, Le 06/04/2023 à 01:46, Dotzero a écrit : > > Not at all. The discussion (and specific post I was responding to) was > about mailing lists but it also applies more generally. A number of > years ago I saw bounces from a Polish domain. Their policy was that if > the From and the Mail From didn't match they would reject the inbound > email. I find that absurdly limiting but they can implement whatever > policy they want. Maybe there are sending domains that do that for all > their mail. My point is that domain owners/admins, at least on certain > levels, get to choose how they interact with other networks/servers. Yeah, but this is where DMARC comes in, and muddies the responsibilities that come with those choices. Originating domains (quoting Todd Herr) just "use p=reject as a signal to declare that they got all outgoing mail authenticated". Evaluators candidly comply with the originator's wish to have unauthenticated mail rejected. None of them is taking responsibility for the breakage they collectively are causing to mailing list (etc…) operation. Avalanches of bounces inflicted upon uninvolved third parties are a major interoperability problem caused by DMARC. This should not happen without either the originator or the evaluator breaking a MUST requirement. Otherwise, DMARC itself is responsible for the breakage. > I also don't think it would be pretty but it's within the realm of > options they can choose from. You talk, but you know they won't really do it. Because they're not trying to coerce you into changing your way of operating. BTW, From munging has not become any "neater" than it was 2 years ago. Or 2 years before. As long as there is no proven solution (ARC?), rehashing the same pseudo-moral arguments is not helpful. Cheers, B. Carvello ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] UNCOL and Reversing modifications from mailing lists
Hi, Le 24/11/2021 à 12:00, Alessandro Vesely a écrit : ARC implies a reliable global reputation system, which only giant providers can afford. Not necessarily. It only imply that the evaluator has some reason to consider acceptable that this particular message be handled by this particular forwarder. If, for example, the evaluator can know for sure that the author designated in the From field really sent a message to the forwarder immediately before the forwarded message came in, the probability that the message is genuine is much higher [1]. Beginning of this month, I proposed an idea to achieve just that. Cheers, Baptiste note [1]: indeed, the attack model then changes from "send a message with a faked From header" (easy) to "somehow have your target send you a genuine message so you can modify and forward it" (possible, but much harder, needs a targeted attack). Only high profile targets need to care about the second type of attack. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC agenda for the IETF 112 session
Hi, > (Direct link to the agenda: > https://datatracker.ietf.org/meeting/112/materials/agenda-112-dmarc ) > > DMARC working group IETF 112 agenda > > 3. Bring discussion of indirect email flows to a close. >Tracking tickets 79, 92, 94, 100, and 122 >We will get to this topic if there's time, but the policy discovery > discussion has priority. if you get to this, and before "closing" this discussion, please consider the following proposals: 1. (already proposed, but I received no feedback): encourage DMARC evaluators to make sure no bounce is generated for REJECT when the message appears to come from a mailing list (silently discarding instead). Bounces coming in by the thousands are no feedback, but sheer aggression. The threat of this aggression allows some DMARC implementers to rely on the mailing list operators to implement workarounds forever (as Ale among others likes to argue). Which makes bootstrapping any new solution difficult. 2. (this proposal is new): complement ARC with a secondary DKIM signature on the first hop. Under this proposal, a DMARC-implementing domain who wants their outgoing mail to be possibly involved in indirect mailflow (most senders do) would appose on each outgoing message a secondary DKIM signature signing the following headers: the recipient address, in a normalized form (here, for example: "To: dmarc@ietf.org"), From, Date and Message-ID. Thus the evaluator could make sure that the ARC signing domain has some relationship with the sender: namely that the sender sent a recent direct message to this intermediary. This in itself doesn't prove that the intermediary is trustworthy, but should make the life of fraudsters sufficiently difficult to deter them in most cases (they would need to first obtain a genuine message from whoever they try to impersonate). Cheers, Baptiste ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
Hi, Le 17/10/2021 à 19:43, Alessandro Vesely a écrit : > > There is no abuse. MLMs act as submitters. Setting From: should be a > must. This all habit of telling other actors what they should or must do has to stop. This hubris is the original sin of Yahoo, which started all the trouble. In a sound interoperation situation, each actor has a bit of wiggle room to assess the situation in their own area of responsibility according to their worldview. Which means for example: * originating domains are free to choose their preferred treatment of DMARC FAILing messages, while remembering to be careful what they wish… * mailing lists can send as their own domain if or when they act as a proper editor, but can also keep the original From field when they act as a technical helper. And they don't need to second-guess evaluators. * evaluators make the final delivery decision based on the originating domain's wishes, but most of all based on their assessment of their users' interest. And yes, they can rewrite whichever headers they feel like, they control their own UX. Corollary to this freedom, there must be incentives to keep each actor accountable. This is where the problem currently lies: the originating domains take no responsibility at all for their choices, which is why Yahoo could get away so easily with their disruptive move. That's why I suggest that REJECTed messages should be silently discarded and thus possibly lost, which makes all actors equally bear the consequences, instead of bounced, which disproportionately punishes the mailing list operators. If it decreases deliverability in the short term, so be it: making all actors accountable is a prerequisite for any consensual solution in the long term. Cheers, Baptiste ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
Le 17/10/2021 à 20:05, Grant Taylor a écrit : On 10/17/21 11:49 AM, Scott Kitterman wrote: Odd, I thought this message was from you, Ale? It depends if you are talking about the content or the SMTP communications path. They say, DMARC chose the "From" field because it is *user-visible*. Users care about who authored the content, not which machines it was relayed over. If you rewrite From, all you do is bring irrelevant complication in the face of the users, and they will quickly learn to ignore it (thereby undermining DMARC in general). Cheers, Baptiste ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
Hi, I'm happy to see the discussion advancing: we now seem to have consensus that redesigning mailing lists behind their backs is a bad idea, and that the existence of From rewriting as an emergency hot-fix does not preclude looking for more satisfactory solutions. Good work! Now, I'm skeptical of your solution. First, I don't think 100% deliverability at all times is a hard requirement. The Open Source mailing lists I care about really don't have a deliverability problem: I'm sure LKML can afford that messages from and/or to a few peculiar domains get lost for a few months, if that's the price to pay to build incentives for a collaborative solution (I don't expect receivers to invest into unmunging if they don't have a strong incentive). Also, having this munging-then-unmunging dance as the *normal* procedure sounds backwards. If the receivers make the delivery decision alone, why can't they implement it all on their side: let the incoming message pass, munge it with an alias under their control, wrap it into a message/rfc822 body part, silently discard it, whatever they want, it's their system, their UX, their users. The only reason for insisting that mailing lists speculatively do the munging on their side is some strange fetish on the value of the From field during transit… where nobody will read it. Oh, and the risk of bounces, of course, which should IMHO be eliminated in this special case. Cheers, Baptiste Le 12/10/2021 à 12:04, Alessandro Vesely a écrit : From: rewriting confers 100% deliverability on messages, but has a bad impact on the end user. If we consider collaborative solutions, we see that, because of their very nature, they cannot cover all cases. So, it is safer to look for collaborative solutions that allow unmunging than to solutions that avoid munging in the first place. Indeed, in the former case the risk is to deliver a munged message, while in the latter one the risk is to either not deliver or not to implement DMARC. Even ARC can be turned into a method to unmunge. It requires collaboration between MLM and receiver. My unmunging method requires cooperation between author's domain, MLM, and receiver. Whitelisting can be done unilaterally by receivers, who can restore the original From: without validating the author's domain signature, just because they trust the MLM. By collecting similar techniques, we might be able to cover almost all cases while still ensuring deliverability. Best Ale On Tue 12/Oct/2021 04:40:12 +0200 Douglas Foster wrote: Barry, you did a nice job of talking me off the ledge. If this is about helping list operators and message evaluators to collaborate in a way that avoids From-Munging, I have no objections. Repeatedly, the topic has seemed to turn in directions that make the evaluator appear irrelevant -- as if the Lists don't need to talk to them. The reality right now is that a lot of From-Munging is unnecessary because: - many evaluators do not enforce DMARC - some evaluators enforce DMARC but have made exceptions for active lists - some other evaluators enforce DMARC and will make exceptions if asked to do so by their users This leaves a small group, like AOL, who enforce DMARC and yet are unresponsive to their users. This small group needs From-Munging, or unmodified messages, or different email accounts for list participation. I claim, without proof, that many of the most vocal critics of From-Munging are using domains that do not require From-Munging on incoming messages. In such cases, the DMARC-enforcing sender is not the real problem, ignorance is. Once the list and the evaluator have agreed to collaborate, we have a bunch of signalling options, including options that survive forwarding. They are mostly simple extensions of things we are already doing, much simpler and more determinative than ARC. Doug Foster . On Mon, Oct 11, 2021 at 10:28 AM Barry Leiba wrote: It's not that the IETF shouldn't be involved with advice on what mailing lists should do. It's that if we should put out a BCP or a standard that says mailing lists MUST NOT alter messages that they forward, those who write mailing list software (and those who deploy it) will not listen. That's where Scott's "we're not the police" statement comes in. For whatever it's worth, mailing lists have been behaving this way for, as others have said, decades, and it has been considered good practice and has been found useful. Mailing lists add footers on messages, whether to advertise the list, to add disclaimers, or whatever. They like it, and won't change. Mailing lists add the list name to the Subject line because it makes it easier to create filters, and because it makes it easier for eyeballs to filter (for the vast majority of users who don't know and don't want to know how to create filters). They like that too, and that, too, won't change. We could advise change, but it would be wasted effort. I
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
Hi, (I'm trimming my own message severely to avoid overwhelming the list) Le 06/10/2021 à 20:22, Alessandro Vesely a écrit : > >> A) The From field >> 1) >> a) > > A list claims some responsibility for the message as well. […] >> b) > > > Right. Yet, posters do trust the MLM operator somewhat. Traditionally, these have been a very weak "some", and a weak "somewhat". Mailing list stem from a time where not everything had to be moderated and sanitized. This old Internet with weak "editors" has served us well, and though some people want it dead, not everybody has to agree. Standards should stay neutral on this political matter. >> 2) > > The usual rewriting is "Baptiste Carvello *via* IETF". It is shorter > than MS's "on behalf of", and hence better. The draft should cover this > detail, IMHO. "via" is better than anything else. Still, that's too much emphasis on what I consider a technical intermediary. >> Any mechanism that rewrites the address alone gives a wrong idea of the >> contact point and thus possibly "hijacks" communication attempts. The >> present proposal is especially egregious in that is does so without any >> hint to the reader. […] > > The "via IETF" or similar wording /is/ a hint. It is both a hint to the > user and a disambiguator for automated address books. This too should > be mentioned in the draft. The draft should be much clarified: I had understood it would use the name alone by default, with some configuration possible for subscribed users (N.B.: not every list is subscriber-only). Still, you're only answering the *easy half* of my paragraph: the hard part is the author's real contact address no more being accessible (with "traditional" munging, you can at least try and guess it; with this draft, you can't even). The alias is only useful if you are a subscriber (I suppose mailing lists won't resend alien mail) and if it is still operating (any free service expires eventually…) In the use case I know best (Open Source development mailing lists), there are good reasons to contact posters, even years after the fact (say you have inquiries about an old design decision). An yes, mailing-list archives often outlive bug/patch trackers. In the worst case, aliases can lead to communication hijacking. That's my point B3), which you didn't answer either. Typically the provider of an Open Source mailing list goes "evil", either with aggressive monetizing a la sourceforge, or by trying to turn the product proprietary. > Which unwrapping are you talking about? I developed an unwrapping > mechanism[*] to be used by the server, not the MUA. […] Yes, that's it, thanks for the pointers. I didn't remember it only kicks in when modifications can be undone. Then, it doesn't create a loophole in DMARC checks, but is only useful for part of the problem (how big a part, your draft doesn't say). >> B) Mailing lists >> 1) >> Fragmenting the ecosystem by creating a new incompatible "blessed by >> DMARC" kind of mailing list is of course worse than everything. > > Why is that incompatible? It's incompatible with the existing usage patterns of mailing lists and expectations of the end users, as informed by 40 years of "tradition". Communication is people talking to people, not domains talking to domains, so you have to take a broad view of backward compatibility when a change leaks up to the UI. >> 2) >> Doug's note on authors' privacy addresses a kind of mailing lists. > IETF's lists are public and publicly archived. Other lists preserve > anonymity. That's not my point. My point is, in the lists I know, preserving anonymity is a bug, not a feature. Hiding the author's real address prevents some useful communication patterns. Granted, addresses in messages bring SPAM, but users already know how to protect themselves. I'm not denying this is a judgment call which you may well disagree with. Standards work however should only consider facts: accessibility of the author's real address is by design, and it has valid use cases. > In all cases, rewriting From: betters a list's deliverability. In other words, it solves the problem DMARC introduced, at the expense of forcing list users to learn new usage patterns. We should not expect them to be grateful :-) >> C) Now what >> 1) > > I agree with Doug on lists not being automatically recognizable as such. It depends for what. A message with a "List-Id" header purports to be a mailing list message. If all you have to decide is whether to bounce a rejected message or just trash it, why not take this affirmation at face
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
Hi, I'll just make a few quick points here, as my message from yesterday was long enough :-) Le 06/10/2021 à 00:30, Douglas Foster a écrit : > > We clearly disagree about whether mailing list SHOULD be a closed > group. Indeed we do, but ultimately it doesn't matter that much. The relevant question is not what mailing lists *should be*, but what they *are*. It just so happens that some people (me included) would rather *not* be protected from «any risk associated with interacting with strangers» by some entity out of their control. Which can also mean taking one's own precautions, as you describe. Still, if I wanted Facebook, I know where to find them (OK, maybe not yesterday :-) > We also disagree about authorship. I argue that a message received > directly from you is very different from a message received via the > list. We indeed disagree. I can understand your point *in theory*. But in practice, mailing lists do not *substantially* modify the contents of the messages. This practice is not ensured through any *technical* means, but through *social* means: reputation, threat of legal action in the worst case… Communication is not just technology. FWIW, I would never post to a mailing list that altered the substance of the messages, *even if* it would also alter the "From" field. > You propose special handling of messages from lists, but you gloss over > the difficulties of identifying a list message. List headers appear > in lots of mass mailings, and any header that cannot be authenticated > cannot be trusted. To clarify my view: I don't believe messages from mailing list should get a free PASS, except maybe as a temporary measure while a solution is devised. What I believe is that DMARC implementers should take their own responsibilities. If a receiving domain decides to enforce p=reject on mailing-list messages, they should *silently discard* the messages and face any related user complaints, not dump the problem onto the mailing lists operators by bouncing. > Currently, lists have an outsized impact on network security. > […] As a result, spammers know that universities are widely respected > that universities are widely respected and easily spoofed, so those > and easily spoofed, so those domains become weapons. You seem to view mailing lists as the only roadblock towards *universal* DMARC adoption and subsequent end of all spoofing. I'm afraid this is way unrealistic… Anyway, asking mailing lists to sacrifice themselves in the name of the greater good (or your view thereof) does not seem like a constructive strategy, nor an efficient one. Any constructive solution should take mailing lists as they are and work with those requirements. Otherwise, the situation will stay as stuck as it has been for several years already. Cheers, Baptiste ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] DMARC-Compliant Mailing Lists
Hi, another season, another "From rewriting" proposal. Once again, it more or less amounts to wishing mailing lists away. So let me try to articulate precisely what is wrong with all those approaches: A) The From field = 0) Unless I missed something, changing the semantics of RFC5322.From, even just for mailing lists, is way off charter for this group. 1) The From field semantics are important not just for interoperability with software systems, but also for "interoperability" with us *humans*, which makes them especially hard to change :-) This human meaning is twofold: a) the "friendly From" conveys *authorship*, that is the (possibly pseudonymal) identity of an *natural person* who claims credit and accepts responsibility for the content. A corporate entity such as a domain is *not* an author. And whatever the "moderation" mechanism, a censor is just that, and will never be an author either. b) the address part provides a *contact point* for the above-defined author, that must be as much as possible *stable* and under the control of an entity *trusted by the author*. 2) All proposed "From rewriting" mechanisms fail at least one of the above requirements. The traditional mechanism blurs the authorship, by introducing a false sense of *affiliation*. This message is authored by "Baptiste Carvello", not "IETF" or even "Baptiste Carvello by IETF". I demand full credit, and I'm sure IETF happily lets me bear full responsibility. Any mechanism that rewrites the address alone gives a wrong idea of the contact point and thus possibly "hijacks" communication attempts. The present proposal is especially egregious in that is does so without any hint to the reader. If this happened to me, I would feel like I'm subject to identity theft, sorry to say. In fact, I lied, the "unwrapping" mechanism could meet both requirements. Except that it is vaporware that no MUA has expressed interest in implementing. And that for all practical purposes, it would be equivalent to disabling DMARC for mailing-list traffic. Quite a loophole, right? B) Mailing lists 1) Again, I question the process of redefining the operating principles of mailing lists in a forum where neither mailing-list operators, nor developers of mailing-list systems or even MUAs are represented. This seems like a recipe for "solving" the wrong problem. Fragmenting the ecosystem by creating a new incompatible "blessed by DMARC" kind of mailing list is of course worse than everything. 2) Specifically, the present proposal fails to take into account that mailing lists are fundamentally different from "closed-group communication systems", not by deficiency, but by *design*. Interoperability with direct e-mail, including the possibility to privately reply to the author (or to temporarily invite non-members by just CC-ing them), is a necessary feature, not a "security hazard" to be fixed. 3) Many (most?) mailing lists are not "intended to be a closed group" living only in the "environment" of their hosting domain. They are communication channels for open communities that have an autonomous existence, and as such should be resilient even to the loss of their mailing-list provider (if it closes shop, or "turns evil"). The community can then only be rescued if users know each-other's real addresses. Aliases would fail you precisely when you need them most! C) Now what === So what's my solution? Well I recognize it's not easy, but a first step could be to mandate that, in the case of DMARC FAIL and p=reject, a message coming in from a mailing list (with a List-Id header) must not be bounced, but *ignored*. The rationale is twofold: 1) Bounces produce no useful result whatsoever, as they never reach back to the originating domain. All they can do is have the recipient users delisted. 2) DMARC incorporates its own reporting mechanism, which goes to the right place. Once DMARC-compliant receivers do this, mailing list operators can remove their workarounds and happily get out of the way. Messages would be lost at first, but DMARC-compliant senders and receivers would collectively bear responsibility for solving *their* problem. Field-testing new solutions would be easier with only two partners, both involved in the DMARC community, than with three. I expect those solutions to be ARC + something… Cheers, Baptiste Le 04/10/2021 à 02:17, Douglas Foster a écrit : > As I hinted in a recent message, I believe that DMARC-compliant mailing > lists are possible. I have posted a draft which explicates how this > can be done. > > Doug Foster > > > -- Forwarded message - > From: mailto:internet-dra...@ietf.org>> > Date: Sun, Oct 3, 2021 at 8:14 PM > Subject: New Versio
