Re: [dmarc-ietf] WGLC contentious topics (I'm in the rough and I know it) in draft-ietf-dmarc-dmarcbis-30

2024-04-01 Thread Baptiste Carvello
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

Re: [dmarc-ietf] Dmarcbis way forward

2023-10-24 Thread Baptiste Carvello
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

Re: [dmarc-ietf] Eliminating From Munging from this list

2023-07-19 Thread Baptiste Carvello
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

Re: [dmarc-ietf] Eliminating From Munging from this list

2023-07-18 Thread Baptiste Carvello
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

Re: [dmarc-ietf] Eliminating From Munging from this list

2023-07-16 Thread Baptiste Carvello
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

Re: [dmarc-ietf] Another p=reject text proposal

2023-07-12 Thread Baptiste Carvello
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

Re: [dmarc-ietf] Another p=reject text proposal

2023-07-12 Thread Baptiste Carvello
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. > >

Re: [dmarc-ietf] Another p=reject text proposal

2023-07-12 Thread Baptiste Carvello
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

Re: [dmarc-ietf] Another p=reject text proposal

2023-07-07 Thread Baptiste Carvello
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

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

2023-04-06 Thread Baptiste Carvello
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

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

2023-04-06 Thread Baptiste Carvello
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

Re: [dmarc-ietf] UNCOL and Reversing modifications from mailing lists

2021-11-24 Thread Baptiste Carvello
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

Re: [dmarc-ietf] DMARC agenda for the IETF 112 session

2021-11-05 Thread Baptiste Carvello
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

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

2021-10-18 Thread Baptiste Carvello
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

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

2021-10-17 Thread Baptiste Carvello
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*.

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

2021-10-13 Thread Baptiste Carvello
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

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

2021-10-07 Thread Baptiste Carvello
d 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 shoul

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

2021-10-06 Thread Baptiste Carvello
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

Re: [dmarc-ietf] DMARC-Compliant Mailing Lists

2021-10-05 Thread Baptiste Carvello
anisms 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 cr