Re: [dmarc-ietf] Signaling MLMs

On Wed 19/Apr/2023 15:50:54 +0200 Benny Pedersen wrote: Alessandro Vesely skrev den 2023-04-19 11:09: if all maillist did arc on incoming mails before mailman scraped dkim then all will be good, only left is dmarc is not in all places tests arc results It is all too easy to spoof an ARC

Re: [dmarc-ietf] Signaling MLMs

Alessandro Vesely skrev den 2023-04-19 11:09: Benny is telling the world “ietf.org [1] is authorize to resign on my behalf” via DNS.  No headers required.  No delayed learning necessary. How would I get a clue of that? reading books ? if all maillist did arc on incomming mails before

Re: [dmarc-ietf] Signaling MLMs

On Wed 19/Apr/2023 01:13:48 +0200 Benny Pedersen wrote: Hector Santos skrev den 2023-04-18 20:47: So your verifier see Benny’s as suspicious because of arc=fail? it does imho not fail on my own arc ? My filter attempts to recover DKIM signatures after MLM transformation, but not ARC

Re: [dmarc-ietf] Signaling MLMs

Hector Santos skrev den 2023-04-18 20:47: So your verifier see Benny’s as suspicious because of arc=fail? it does imho not fail on my own arc ? Benny is telling the world “ietf.org [1] is authorize to resign on my behalf” via DNS. No headers required. No delayed learning necessary. if

Re: [dmarc-ietf] Signaling MLMs

> On Apr 18, 2023, at 12:24 PM, Alessandro Vesely wrote: > > What's the point of wearing an atps record if it's not called out in a DKIM > signature? (I wouldn't have tested it anyway). Alessandro, you are already doing the DNS call for DMARC. Hitch a ride!! You can check for atps=y or

Re: [dmarc-ietf] Signaling MLMs

On Tue 18/Apr/2023 00:48:30 +0200 Benny Pedersen wrote: Hector Santos skrev den 2023-04-17 20:55: One solution is for the junc.eu domain to add an ATPS authorization record for ietf.org [1] to the junc.eu [2] zone: pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps  TXT ("v=atps01; d=ietf.org;") retest

Re: [dmarc-ietf] Signaling MLMs

On 4/17/2023 6:48 PM, Benny Pedersen wrote: Hector Santos skrev den 2023-04-17 20:55: One solution is for the junc.eu domain to add an ATPS authorization record for ietf.org [1] to the junc.eu [2] zone: pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT ("v=atps01; d=ietf.org;") retest [3]

Re: [dmarc-ietf] Signaling MLMs

Hector Santos skrev den 2023-04-17 20:55: One solution is for the junc.eu domain to add an ATPS authorization record for ietf.org [1] to the junc.eu [2] zone: pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT ("v=atps01; d=ietf.org;") retest [3] https://winserver.com/public/wcDmarc

Re: [dmarc-ietf] Signaling MLMs

Hector Santos skrev den 2023-04-17 20:55: Just consider your message source. The header overhead is massively complex to read. It is really a waste on receivers. Apr 17 22:53:28.015 [22350] dbg: authres: parsing Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key)

Re: [dmarc-ietf] Signaling MLMs

> On Apr 16, 2023, at 11:31 PM, Benny Pedersen wrote: > > Hector Santos skrev den 2023-04-17 05:06: > >> Anyway, there are far too much waste in electronic mail, ADSP/DMARC >> and this quest to resolve its issues, creating more junk, ARC, is not >> getting anywhere. > > ?, spamassassin 4, do

Re: [dmarc-ietf] Signaling MLMs

Hector Santos skrev den 2023-04-17 05:06: Anyway, there are far too much waste in electronic mail, ADSP/DMARC and this quest to resolve its issues, creating more junk, ARC, is not getting anywhere. ?, spamassassin 4, do something, i use fuglu in prequeue smtpd postfix, works for me atleast,

Re: [dmarc-ietf] Signaling MLMs

On 4/16/2023 8:43 PM, Neil Anuskiewicz wrote: Hector, respecfully, I disagree with several of your points. * You seemes to be saying that when spf fails then usually dkim fails, too. I’ve seen first hand that’s nit true. Yes, most of the times. The exceptions are the true forwards. It's

Re: [dmarc-ietf] Signaling MLMs

On 4/15/2023 6:53 AM, Alessandro Vesely wrote: I only know a handful of mailing lists, and they all do From: rewriting. Some took years to adapt, but eventually adapted. Are there any who don't? Since 1996, wcListServer. I agree lists may also refuse participation and require posters to

Re: [dmarc-ietf] Signaling MLMs

> On Apr 15, 2023, at 6:56 AM, Jesse Thompson wrote: > >  >> On Fri, Apr 14, 2023, at 10:24 PM, Scott Kitterman wrote: >> On Friday, April 14, 2023 10:31:33 PM EDT Jesse Thompson wrote: >> > On Fri, Apr 14, 2023, at 7:17 PM, Murray S. Kucherawy wrote: >> > > The Sender's users being denied

Re: [dmarc-ietf] Signaling MLMs

 > On Apr 15, 2023, at 7:29 AM, Scott Kitterman wrote: >  > >> On April 15, 2023 12:26:16 PM UTC, Laura Atkins >> wrote: >> On Apr 15, 2023, at 4:25 AM, Scott Kitterman wrote: > ... >>> Or [person] gets a Gmail account for his IETF work and doesn't bother >>> tilting at >>> windmills. >>

Re: [dmarc-ietf] Signaling MLMs

> On Apr 15, 2023, at 7:29 AM, Scott Kitterman wrote: > >  > >> On April 15, 2023 12:26:16 PM UTC, Laura Atkins >> wrote: >> On Apr 15, 2023, at 4:25 AM, Scott Kitterman wrote: > ... >>> Or [person] gets a Gmail account for his IETF work and doesn't bother >>> tilting at >>> windmills.

Re: [dmarc-ietf] Signaling MLMs

On Apr 15, 2023, at 7:52 AM, Hector Santos wrote:On Apr 14, 2023, at 7:31 PM, Dotzero wrote:On Fri, Apr 14, 2023 at 5:55 PM Hector Santos isdg.net> wrote:Yes, it is simple DeMorgan’s Theorem where you use short-circuiting logic.DMARC says that any FAIL calculated via SPF or DKIM is an overall

Re: [dmarc-ietf] Signaling MLMs

It appears that Scott Kitterman said: > > >On April 15, 2023 12:26:16 PM UTC, Laura Atkins >wrote: >>On Apr 15, 2023, at 4:25 AM, Scott Kitterman wrote: >>It seems to me that there is zero harm in actively documenting the problems >>with DMARC and making interoperability >recommendations

Re: [dmarc-ietf] Signaling MLMs

RFC 5321 restrictions on forwarding cease to be applicable when the message is modified. Once the MLM changes the message, the ML domain owns it, which is why the MLM-created message SHOULD use the ML domain on the new message. Additionally: - The recipient may not trust the author domain, for

Re: [dmarc-ietf] Signaling MLMs

On Sat 15/Apr/2023 18:10:08 +0200 Scott Kitterman wrote: On Saturday, April 15, 2023 11:45:34 AM EDT Alessandro Vesely wrote: On Sat 15/Apr/2023 16:42:32 +0200 Scott Kitterman wrote: On April 15, 2023 1:55:59 PM UTC, Jesse Thompson wrote: And the "If a mailing list would like to provide the

Re: [dmarc-ietf] Signaling MLMs

On Sat 15/Apr/2023 04:57:13 +0200 Murray S. Kucherawy wrote: On Fri, Apr 14, 2023 at 7:32 PM Jesse Thompson wrote: On Fri, Apr 14, 2023, at 7:17 PM, Murray S. Kucherawy wrote: The Sender's users being denied the ability to participate in a list due to its policies seems to me like it puts

Re: [dmarc-ietf] Signaling MLMs

On Saturday, April 15, 2023 11:45:34 AM EDT Alessandro Vesely wrote: > On Sat 15/Apr/2023 16:42:32 +0200 Scott Kitterman wrote: > > On April 15, 2023 1:55:59 PM UTC, Jesse Thompson wrote: > >>And the "If a mailing list would like to provide the best customer > >>experience...MUST rewrite"

Re: [dmarc-ietf] Signaling MLMs

On Sat 15/Apr/2023 16:42:32 +0200 Scott Kitterman wrote: On April 15, 2023 1:55:59 PM UTC, Jesse Thompson wrote: And the "If a mailing list would like to provide the best customer experience...MUST rewrite" suggestion seems like a reasonable way out of this "interoperability vs reality"

Re: [dmarc-ietf] Signaling MLMs

> On Apr 14, 2023, at 7:31 PM, Dotzero wrote: > > On Fri, Apr 14, 2023 at 5:55 PM Hector Santos > wrote: >> Yes, it is simple DeMorgan’s Theorem where you use short-circuiting logic. >> >> DMARC says that any FAIL calculated via SPF or DKIM is an overall

Re: [dmarc-ietf] Signaling MLMs

On April 15, 2023 1:55:59 PM UTC, Jesse Thompson wrote: >On Fri, Apr 14, 2023, at 10:24 PM, Scott Kitterman wrote: >> On Friday, April 14, 2023 10:31:33 PM EDT Jesse Thompson wrote: >> > On Fri, Apr 14, 2023, at 7:17 PM, Murray S. Kucherawy wrote: >> > > The Sender's users being denied the

Re: [dmarc-ietf] Signaling MLMs

On April 15, 2023 12:26:16 PM UTC, Laura Atkins wrote: >On Apr 15, 2023, at 4:25 AM, Scott Kitterman wrote: ... >> Or [person] gets a Gmail account for his IETF work and doesn't bother >> tilting at >> windmills. > >That solution only works until gmail publishes p=reject. At one point they

Re: [dmarc-ietf] Signaling MLMs

I can support Todd's language: "Domain Owner MUST provide a domain with p=none for mailing list participants" because it presupposes participation with a mailing list, in particular a mailing list that presumes a right to modify content in transit. Mailing lists are not the only cause of

Re: [dmarc-ietf] Signaling MLMs

On Fri, Apr 14, 2023, at 10:24 PM, Scott Kitterman wrote: > On Friday, April 14, 2023 10:31:33 PM EDT Jesse Thompson wrote: > > On Fri, Apr 14, 2023, at 7:17 PM, Murray S. Kucherawy wrote: > > > The Sender's users being denied the ability to participate in a list due > > > to its policies seems to

Re: [dmarc-ietf] Signaling MLMs

On Apr 15, 2023, at 4:25 AM, Scott Kitterman wrote: > > On Friday, April 14, 2023 10:31:33 PM EDT Jesse Thompson wrote: >>> On Fri, Apr 14, 2023, at 7:17 PM, Murray S. Kucherawy wrote: >>> The Sender's users being denied the ability to participate in a list due >>> to its policies seems to me

Re: [dmarc-ietf] Signaling MLMs

On Friday, April 14, 2023 10:31:33 PM EDT Jesse Thompson wrote: > On Fri, Apr 14, 2023, at 7:17 PM, Murray S. Kucherawy wrote: > > The Sender's users being denied the ability to participate in a list due > > to its policies seems to me like it puts this customer service problem > > where it

Re: [dmarc-ietf] Signaling MLMs

On Fri, Apr 14, 2023 at 7:32 PM Jesse Thompson wrote: > On Fri, Apr 14, 2023, at 7:17 PM, Murray S. Kucherawy wrote: > > The Sender's users being denied the ability to participate in a list due > to its policies seems to me like it puts this customer service problem > where it belongs. > > >

Re: [dmarc-ietf] Signaling MLMs

On Fri, Apr 14, 2023, at 7:17 PM, Murray S. Kucherawy wrote: > The Sender's users being denied the ability to participate in a list due to > its policies seems to me like it puts this customer service problem where it > belongs. Let's say, tomorrow, IETF configures this list to reject Todd's

Re: [dmarc-ietf] Signaling MLMs

On Fri, Apr 14, 2023, 14:51 Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Interoperability problems occur because MLMs believe they are exempt from > the security problems that lesser mortals face. > This isn't true. Interoperability problems started when senders posted a

Re: [dmarc-ietf] Signaling MLMs

On Fri, Apr 14, 2023 at 5:55 PM Hector Santos wrote: > Yes, it is simple DeMorgan’s Theorem where you use short-circuiting logic. > > DMARC says that any FAIL calculated via SPF or DKIM is an overall DMARC > failure. In standard boolean logic is it an OR condition: > > IF SPF FAILS or DKIM

Re: [dmarc-ietf] Signaling MLMs

Yes, it is simple DeMorgan’s Theorem where you use short-circuiting logic. DMARC says that any FAIL calculated via SPF or DKIM is an overall DMARC failure. In standard boolean logic is it an OR condition: IF SPF FAILS or DKIM FAILS Then Reject. I hope you can understand this technical

Re: [dmarc-ietf] Signaling MLMs

Interoperability problems occur because MLMs believe they are exempt from the security problems that lesser mortals face. I am not obligated to deliver every message that arrives for my users. If DMARC causes an evaluator to block a message that his user wants, they have a customer service

Re: [dmarc-ietf] Signaling MLMs

Hector, it sounds like you are saying that SPF is all we need, so scrap DMARC. If it is something else please clarify. Doug On Fri, Apr 14, 2023, 4:44 PM Hector Santos wrote: > > > On Apr 14, 2023, at 3:20 PM, Murray S. Kucherawy > wrote: > > On Fri, Apr 14, 2023 at 10:20 AM Alessandro

Re: [dmarc-ietf] Signaling MLMs

> On Apr 14, 2023, at 3:20 PM, Murray S. Kucherawy wrote: > > On Fri, Apr 14, 2023 at 10:20 AM Alessandro Vesely > wrote: >> On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote: >> > On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" >> >

Re: [dmarc-ietf] Signaling MLMs

On Fri, Apr 14, 2023 at 10:20 AM Alessandro Vesely wrote: > On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote: > > On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" < > superu...@gmail.com> wrote: > >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely > wrote: > >> > >>> Heck, MLMs

Re: [dmarc-ietf] Signaling MLMs

The solution to move forward is: - Recommend MUST NOT publish if domain wants to allow users to use domain in public list systems, - Warn MLS/MLS to avoid From Rewrite and recommend to honor p=reject by rejecting subscription, submissions. This is already in practice since 2011. - Update

Re: [dmarc-ietf] Signaling MLMs

On Friday, April 14, 2023 1:20:28 PM EDT Alessandro Vesely wrote: > On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote: > > On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" wrote: > >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely wrote: > >>> Heck, MLMs should start rejecting

Re: [dmarc-ietf] Signaling MLMs

On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote: On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" wrote: On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely wrote: Heck, MLMs should start rejecting messages sent from domains that publish a blocking policy *when they fail

Re: [dmarc-ietf] Signaling MLMs

The situation will converge to two separate but unequal environments, those that prioritize security, and those that require insecurity. As people get burned, the pro-security segment will grow and the insecure segment will find more and more restrictions on their ability to connect to their

Re: [dmarc-ietf] Signaling MLMs

On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" wrote: >On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely wrote: > >> Heck, MLMs should start rejecting messages sent from domains that publish >> a >> blocking policy *when they fail authentication on entry*!! >> > >That's not enough to

Re: [dmarc-ietf] Signaling MLMs

On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely wrote: > Heck, MLMs should start rejecting messages sent from domains that publish > a > blocking policy *when they fail authentication on entry*!! > That's not enough to avoid the damage we're talking about. > From: rewriting is the de-facto

Re: [dmarc-ietf] Signaling MLMs

On Thu 13/Apr/2023 17:57:55 +0200 Dotzero wrote: On Wed, Apr 12, 2023 at 11:38 PM Murray S. Kucherawy wrote: On Wed, Apr 12, 2023 at 12:45 PM Steven M Jones wrote: In any case, are we really going to start suggesting that list operators start rejecting messages sent from domains that

Re: [dmarc-ietf] Signaling MLMs

> On Apr 13, 2023, at 4:33 PM, John Levine wrote: > >> (2) An author domain can decide to affix this at its discretion, ... > > The basic problem is that author domains lie about their policy, i.e., > p=none but they expect mailing lists to work, and their users are > stuck. It’s not a lie.

Re: [dmarc-ietf] Signaling MLMs

It appears that Murray S. Kucherawy said: >(1) MLMs don't necessarily want to start doing DNS queries. They operate >just fine never touching the DNS today; this is a new dependency and bunch >of stuff they have to learn to apply and suppot. Depends how they're set up. In the common case that

Re: [dmarc-ietf] Signaling MLMs

On 4/13/2023 11:14 AM, Barry Leiba wrote: There's no need for a signal here: the MLM can simply check the sending domain's DMARC policy when a new post comes in, and preemptively reject it if the policy is "reject". The IETF considered doing that and ruled it out because it would mean that

Re: [dmarc-ietf] Signaling MLMs

On Wed, Apr 12, 2023 at 11:38 PM Murray S. Kucherawy wrote: > On Wed, Apr 12, 2023 at 12:45 PM Steven M Jones wrote: > >> This puts me in mind of Section 8.5, which calls out some potential >> impacts of blocking policies to "Mediators," which role doesn't otherwise >> appear very often in this

Re: [dmarc-ietf] Signaling MLMs

On Thu, Apr 13, 2023 at 8:14 AM Barry Leiba wrote: > There's no need for a signal here: the MLM can simply check the > sending domain's DMARC policy when a new post comes in, and > preemptively reject it if the policy is "reject". The IETF considered > doing that and ruled it out because it

Re: [dmarc-ietf] Signaling MLMs

I would like to make the receiving advice stronger *also*, yes. In particular, I would change the SHOULD NOT to MUST NOT, and I would add text that suggests that it's a particularly bad idea to react to p=reject for domains that are known to host email addresses for the general public, and expand

Re: [dmarc-ietf] Signaling MLMs

> I've also been thinking about ways to push the burden back on the > advertisers. Imagine we have some kind of signaling mechanism that > MLMs can take advantage of indicating to them that the author is using > a strong policy, and so it would be possibly a bad idea for the MLM to > accept,

Re: [dmarc-ietf] Signaling MLMs

On Wed, Apr 12, 2023 at 11:35 PM Murray S. Kucherawy wrote: > On Wed, Apr 12, 2023 at 11:41 AM Todd Herr 40valimail@dmarc.ietf.org> wrote: > >> On Wed, Apr 12, 2023 at 2:16 PM Murray S. Kucherawy >> wrote: >> >>> I've been thinking about the point a few people have made now that DMARC >>>

Re: [dmarc-ietf] Signaling MLMs

On 4/12/2023 11:38 PM, Murray S. Kucherawy wrote: On Wed, Apr 12, 2023 at 12:45 PM Steven M Jones > wrote: ISTR there were some vocal and visible mailing list operators that were rejecting messages from domains that published "p=reject" policies, maybe around

Re: [dmarc-ietf] Signaling MLMs

I am beginning work on a Best Practices document which will attempt to explain what evaluators should understand about p=reject. Topics to include: - PASS is more important than FAIL - SPF and DMARC are not the end of authentication options. Any message can be authenticated for the

Re: [dmarc-ietf] Signaling MLMs

On Wed, Apr 12, 2023 at 12:45 PM Steven M Jones wrote: > This puts me in mind of Section 8.5, which calls out some potential > impacts of blocking policies to "Mediators," which role doesn't otherwise > appear very often in this document. Is there any need to add Mediator >

Re: [dmarc-ietf] Signaling MLMs

On Wed, Apr 12, 2023 at 11:41 AM Todd Herr wrote: > On Wed, Apr 12, 2023 at 2:16 PM Murray S. Kucherawy > wrote: > >> I've been thinking about the point a few people have made now that DMARC >> has two actors that cause the problem: Those who "blindly" apply >> "p=reject", and those who

Re: [dmarc-ietf] Signaling MLMs

> On Apr 12, 2023, at 2:15 PM, Murray S. Kucherawy wrote: > > I've been thinking about the point a few people have made now that DMARC has > two actors that cause the problem: Those who "blindly" apply "p=reject", and > those who advertise "p=reject". You do, indeed, need two to tango; >

Re: [dmarc-ietf] Signaling MLMs

On 4/12/23 11:15 AM, Murray S. Kucherawy wrote: The MLM can then decide if it is willing to pass the message unmodified to the list, or reject it with an error like "The policies of this list require modification of your message, which violates your domain's apparent policy.  Your submission

Re: [dmarc-ietf] Signaling MLMs

My own feeling is that lists should have a service agreement / disclosure statement that says, "We will modify your text in {manner} for {reason}.". "We will do {feature} to reduce the risk of unwanted or dangerous list posts". "We will do {feature} to minimize use of off-topic posts. The

Re: [dmarc-ietf] Signaling MLMs

On Wed, Apr 12, 2023 at 2:16 PM Murray S. Kucherawy wrote: > I've been thinking about the point a few people have made now that DMARC > has two actors that cause the problem: Those who "blindly" apply > "p=reject", and those who advertise "p=reject". You do, indeed, need two > to tango;

[dmarc-ietf] Signaling MLMs

I've been thinking about the point a few people have made now that DMARC has two actors that cause the problem: Those who "blindly" apply "p=reject", and those who advertise "p=reject". You do, indeed, need two to tango; enforcement doesn't happen without an advertising sender and a participating