FYI: After some unfruitful offlist communication with Noel we finally
took the step and unsubscribed him from the mailop mailinglist and we do
not intend to let him subscribe this list again.
p@rick
mailop postmaster team
Am 19.06.22 um 09:02 schrieb Noel Butler via mailop:
I dont
On 24/06/2022 17:54, Alessandro Vesely via mailop wrote:
On Wed 22/Jun/2022 13:31:49 +0200 Slavko via mailop wrote:
Neither I use it. I didn't know rspamd implements ARC. Most of that
module's documentation seems to be about signing, which is not
difficult. But there is a
Hi,
Dňa 24. júna 2022 16:54:29 UTC používateľ Alessandro Vesely via mailop
napísal:
>Yup, that seems to have become a de facto standard. However, I also
>set an Author: header field, just in case.
Thanks to point me to Author: header, i miss it previously, but see
below...
>My filter tries
On Wed 22/Jun/2022 13:31:49 +0200 Slavko via mailop wrote:
Dňa Tue, 21 Jun 2022 17:17:47 +0200 Alessandro Vesely via mailop
napísal:
From: munging turned out to be the best way that SMTP+DKIM+DMARC go
together. I understand that those who miss unmunging can feel
slightly annoyed.
If i
On Wed, Jun 22, 2022 at 6:04 PM Dave Crocker wrote:
> OK. So you are suggesting something that is independent of
> spf/dkim/dmarc/arc? That's fine, I guess, but I thought this thread was
> discussing those.
Apologies. I hijacked this thread. Taking the discussion offline.
Rob
On 6/22/2022 4:21 PM, Rob Nagler via mailop wrote:
On Tue, Jun 21, 2022 at 9:54 PM Dave Crocker wrote:
> None of the relevant systems have C-R as a component, so I'm guessing
> you mean this as an exemplar of the background stuff that happens
> magically, to get an actor to be authorized
On Tue, Jun 21, 2022 at 9:54 PM Dave Crocker wrote:
> Within the NIST context, this might qualify as a kind of 'user', but
> resolving that 'might' would indeed get into quibbling.
Agreed.
> None of the relevant systems have C-R as a component, so I'm guessing
> you mean this as an exemplar of
Ahoj,
Dňa Tue, 21 Jun 2022 17:17:47 +0200 Alessandro Vesely via mailop
napísal:
> From: munging turned out to be the best way that SMTP+DKIM+DMARC go
> together. I understand that those who miss unmunging can feel
> slightly annoyed.
If i properly understand the unmunge term, how to unmunge
On 6/21/2022 8:25 PM, Rob Nagler via mailop wrote:
Dave Crocker continues:
> The existing repertoire of relevant email tech specs are for
> authentication, except for SPF, which includes authorization of SMTP
> client engines, and DMARC, which include rfc5321.From field domain name
>
On Tue, Jun 21, 2022 at 5:34 PM John Levine wrote:
> I think you underestimate the persistence and bad faith of spammers.
I certainly don't.
> That also doesn't scale. There are at least 100,000 mail systems on
> the Internet. How many complaints per second are you prepared to
> investigate
On 6/20/2022 8:59 AM, Rob Nagler via mailop wrote:
IMHO, the problem is a lack of a public trust model. ARC, SPF, and DKIM
do not solve the trust problem. There should be some FOSS that
implements the model (just like certbot implements ACME).
We still need virus/spam detection algorithms.
According to Rob Nagler via mailop :
>We could still have a public trust system that didn't require everybody to
>agree on this concept. What needs to be known is to define publicly how to
>fix your (authenticated) reputation at any given ADMD. If you have a
>content (or otherwise) problem with a
On Tue, Jun 21, 2022 at 7:02 AM Bill Cole wrote:
> Rewriting header and envelope addresses is as old as Sendmail.
>
>
> I'm mystified by your distinction between rewriting the envelope sender
> and "managing bounce addresses."
Since this has been a discussion of history, one used to be able to
On 6/21/2022 9:20 AM, Alessandro Vesely via mailop wrote:
Mail forwarded by gmail, for example, has an X-Google-DKIM-Signature but
is not otherwise DKIM-signed. It is ARC-sealed. (Brandon Long
explained why a couple of years ago[*]).
Hmmm. Sorry I missed his message when it originally
On Tue 21/Jun/2022 15:40:51 +0200 John Levine via mailop wrote:
According to Alessandro Vesely via mailop :
"Some responsibility" is quite a long way from "ownership". It was phrased to
refer to any sort of handling or even analysis involvement.
Yet, ARC sounds like a way to permit an
On Tue 21/Jun/2022 12:06:16 +0200 Slavko via mailop wrote:
Dňa 21. 6. o 9:07 Alessandro Vesely via mailop napísal(a):
Section 3.9 is perhaps the worst one in that document. By that wording, the
addition of /any/ header field is forbidden, including List-*.
IMO it describes headers change,
According to Alessandro Vesely via mailop :
>> "Some responsibility" is quite a long way from "ownership". It was phrased
>> to
>> refer to any sort of handling or even analysis involvement.
>
>Yet, ARC sounds like a way to permit an organization to claim /somewhat less/
>responsibility for a
On 6/21/2022 12:07 AM, Alessandro Vesely via mailop wrote:
RFC 5321, sect. 3.9 Mailing Lists and Aliases
...
When a message is delivered or forwarded to each address of an
expanded list form, the return address in the envelope ("MAIL
FROM:")
MUST be changed to be the
On 2022-06-20 at 23:25:49 UTC-0400 (Mon, 20 Jun 2022 21:25:49 -0600)
Rob Nagler via mailop
is rumored to have said:
On Mon, Jun 20, 2022 at 12:17 PM Bill Cole wrote:
Which part?
"That form of mailing list was already dying out 20 years ago"
I don't think people were rewriting From: or
Dňa 21. 6. o 9:07 Alessandro Vesely via mailop napísal(a):
Section 3.9 is perhaps the worst one in that document. By that wording,
the addition of /any/ header field is forbidden, including List-*.
IMO it describes headers change, not headers addition.
But worst one from that RFC? Why?
On Sun 19/Jun/2022 14:15:51 +0200 Dave Crocker via mailop wrote:
On 6/17/2022 9:35 PM, Brandon Long via mailop wrote:
DKIM implies ownership that one doesn't want to use for relaying.
FWIW, that interpretation of DKIM semantics goes beyond the DKIM specification,
which, instead says:
On Mon 20/Jun/2022 20:18:04 +0200 Jaroslaw Rafa wrote:
Dnia 20.06.2022 o godz. 20:05:37 Jaroslaw Rafa via mailop pisze:
Mailing lists can operate minimal changes, like this list does, for example.
I received your message with "From: Jaroslaw Rafa " after
my filter verified that your DKIM
On Mon 20/Jun/2022 19:48:50 +0200 Slavko via mailop wrote:
Dňa 20. júna 2022 16:53:41 UTC používateľ Alessandro Vesely via mailop
napísal:
Plus, use of SPF with DMARC - even with rewriting - causes the same problem
as with mailing lists.
Yes, you have to rewrite From: as well, if you alter
On Mon, Jun 20, 2022 at 12:17 PM Bill Cole wrote:
> Which part?
"That form of mailing list was already dying out 20 years ago"
I don't think people were rewriting From: or envelope from at that time.
They were managing bounce addresses.
To test my conjecture, I downloaded mailman-2.1.15
That is configurable since mailman 2.1.18. Details:
https://wiki.list.org/DEV/DMARC
On Mon, Jun 20, 2022 at 11:22 AM Jaroslaw Rafa via mailop
wrote:
> Dnia 20.06.2022 o godz. 20:05:37 Jaroslaw Rafa via mailop pisze:
> > > Mailing lists can operate minimal changes, like this list does, for
>
Dnia 20.06.2022 o godz. 15:27:10 Bill Cole via mailop pisze:
>
> From your message, as received here:
>
> From: Jaroslaw Rafa via mailop
> Reply-To: Jaroslaw Rafa
>
> Common Mailman behavior.
Yes, common (that's exactly what I'm writing about), but "common" doesn't
mean "correct" nor
On 2022-06-20 at 14:18:04 UTC-0400 (Mon, 20 Jun 2022 20:18:04 +0200)
Jaroslaw Rafa via mailop
is rumored to have said:
> Dnia 20.06.2022 o godz. 20:05:37 Jaroslaw Rafa via mailop pisze:
>>> Mailing lists can operate minimal changes, like this list does, for example.
>>> I received your message
On 2022-06-20 at 11:59:55 UTC-0400 (Mon, 20 Jun 2022 09:59:55 -0600)
Rob Nagler via mailop
is rumored to have said:
> On Mon, Jun 20, 2022 at 8:16 AM Bill Cole wrote:
>> That claim does apply to the simplest sort of mailing list, implemented
>> simply as an alias that 'explodes' into multiple
> On 20 Jun 2022, at 18:05, Al Iverson via mailop wrote:
>
> I didn't really "get" ARC when it comes to mailing lists, there seems
> to be little point, as I felt that most people already dealt with
> mailing lists under DMARC via header rewriting.
Header rewriting is awful if you’re using
Dnia 20.06.2022 o godz. 20:05:37 Jaroslaw Rafa via mailop pisze:
> > Mailing lists can operate minimal changes, like this list does, for example.
> > I received your message with "From: Jaroslaw Rafa " after
> > my filter verified that your DKIM signature still validates upon undoing
> > their
Dnia 20.06.2022 o godz. 18:53:41 Alessandro Vesely via mailop pisze:
> > been discussed here multiple times. So mailing list would have to rewrite
> > the header-from of the messages, which indeed some mailing lists do (eg.
> > Google Groups), but I consider this being more a problem than a
On Mon, Jun 20, 2022 at 11:41 AM Paulo Pinto via mailop
wrote:
>
> >ARC is motivated by the cases where DKIM/SPF/DMARC information about the
> >author/originator get broken.
>
> I'm truly trying to find a justification to break DKIM/SPF on a message after
> it is sent.
I don't know why people
Dňa 20. júna 2022 16:53:41 UTC používateľ Alessandro Vesely via mailop
napísal:
>> Plus, use of SPF with DMARC - even with rewriting - causes the same problem
>> as with mailing lists.
>
>
>Yes, you have to rewrite From: as well, if you alter the message.
RFC 5321, sect. 3.9 Mailing Lists and
On 20 Jun 2022, at 16:59, Rob Nagler via mailop wrote:
> I looked at mailop's history, and it was a simple reflector in 2018, less
> than 5 years ago.
That piqued my interest - it has never been a "simple reflector", it's been
using Mailman 2.x from the very beginning.
What happened
On 6/20/2022 9:05 AM, Paulo Pinto via mailop wrote:
>ARC is motivated by the cases where DKIM/SPF/DMARC information about the
>author/originator get broken.
I'm truly trying to find a justification to break DKIM/SPF on a message
after it is sent.
SPF is designed to be extremely fragile.
On Sun 19/Jun/2022 11:32:14 +0200 Jaroslaw Rafa wrote:
Dnia 19.06.2022 o godz. 08:40:18 Noel Butler via mailop pisze:
I was a very early (even in testing) user of SPF, It's rather commical
reading these FUD sayers about SPF and mailing lists, it has never been a
problem with mailing lists,
: mailop@mailop.org
Subject: Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal
I have heard, and in the past made, the “SPF breaks mailing lists” but I
stopped saying it because it’s not true in the vast majority of cases. For
instance, the 5321.from on this list is
boun...@mailop.org
>ARC is motivated by the cases where DKIM/SPF/DMARC information about the
>author/originator get broken.
I'm truly trying to find a justification to break DKIM/SPF on a message
after it is sent.
SPF -> You should be aware of all the servers that can be involved in the
message transaction so no
It appears that Laura Atkins via mailop said:
>However, SPF breaks even with basic MTA relaying, nevermind mailing lists --
>unless the MTA is registered in the SPF record.
>The delivery/re-post behavior of mailing lists not only breaks SPF but almost
>always also breaks DKIM. (This latter
On Mon, Jun 20, 2022 at 8:16 AM Bill Cole wrote:
> That claim does apply to the simplest sort of mailing list, implemented
> simply as an alias that 'explodes' into multiple recipients.
>
> That form of mailing list was already dying out 20 years ago when SPF
> was being specified. I expect that
On 6/19/2022 7:04 PM, Ángel via mailop wrote:
Mailing lists must use their own envelope from when injecting list
messages to the subscribers.
Should and do. Not must. There's no formal requirement, just practical
choice.
But, yeah, changing the rfc5321.mailfrom to an addresss of the
On 2022-06-20 at 07:35:19 UTC-0400 (Mon, 20 Jun 2022 12:35:19 +0100)
Laura Atkins via mailop
is rumored to have said:
Most modern mailing lists rewrite the 5321.from by default so they can
bounce handle. I don’t think SPF breaks mailing lists as much as
folks claim.
That claim does apply to
> On 19 Jun 2022, at 20:22, Dave Crocker via mailop wrote:
>
> It occurred to me that it might help for me to provide more context to the
> questions I asked. I was possibly relying too much on the thread context...
>
>
> On 6/18/2022 3:40 PM, Noel Butler via mailop wrote:
>
>> I was a
Dave Crocker said:
The challenge to the receiving site, then, is to decide whether to
> believe that evaluating intermediary site (as well as then deciding on
> an evaluation or the originating site.
>
This is exactly the point that I was making earlier and I 100% agree with
that. In order for
On 2022-06-19 at 12:22 -0700, Dave Crocker wrote:
> On 6/18/2022 3:40 PM, Noel Butler via mailop wrote:
>
> > I was a very early (even in testing) user of SPF, It's rather commical
> > reading these FUD sayers about SPF and mailing lists, it has never been
> > a problem with mailing lists, not
It occurred to me that it might help for me to provide more context to
the questions I asked. I was possibly relying too much on the thread
context...
On 6/18/2022 3:40 PM, Noel Butler via mailop wrote:
I was a very early (even in testing) user of SPF, It's rather commical
reading these
On 6/17/2022 6:17 AM, Paulo Pinto via mailop wrote:
tldr; what ARC tries to address is already correctly handled by
DKIM/SPF/DMARC if used as designed.
None of those provide an authenticated handling record in the message.
ARC is motivated by the cases where DKIM/SPF/DMARC information about
On 6/17/2022 9:35 PM, Brandon Long via mailop wrote:
DKIM implies ownership that one doesn't want to use for relaying.
FWIW, that interpretation of DKIM semantics goes beyond the DKIM
specification, which, instead says:
"DomainKeys Identified Mail (DKIM) permits a person, role, or
On 6/19/2022 12:02 AM, Noel Butler via mailop wrote:
I dont respond to smart arse trolls who have nothing better to do than
try bait people, youve been around long enough to know exactly what I
was talking about its nothing to do with lists its email standards if
you dont understand that put
Dnia 19.06.2022 o godz. 08:40:18 Noel Butler via mailop pisze:
>
> I was a very early (even in testing) user of SPF, It's rather commical
> reading these FUD sayers about SPF and mailing lists, it has never been a
> problem with mailing lists, not using mailman nor its more common
> predecessor
I dont respond to smart arse trolls who have nothing better to do than
try bait people, youve been around long enough to know exactly what I
was talking about its nothing to do with lists its email standards if
you dont understand that put your bottle down, sober up, and itll come
back to you
On 6/18/2022 3:40 PM, Noel Butler via mailop wrote:
As for forwarding, SPF is only a problem if you dont follow standards
and re-write
Hi.
You don't indicate what kind of rewriting you mean. It probably doesn't
matter, since you seem to feel that mailing lists have to follow some
On 19/06/2022 00:03, Jaroslaw Rafa via mailop wrote:
this thread (forwarding or mailing lists). That was the main goal of
SPF -
ensuring that the message isn't fake - and it cannot even fulfill that
one
goal properly. Why even use it at all?
I was a very early (even in testing) user of SPF,
Dnia 17.06.2022 o godz. 21:35:08 Brandon Long via mailop pisze:
> There is a limit to the utility of that thing, however, ie SPF passing doesn't
> mean a message isn't spam,
And the reverse is true as well - SPF failing doesn't mean the message is
spam. Neither does it mean it is fake - just
SRS isn't anything, it was a draft that went nowhere and has no mechanism
for authentication. It's basically the same thing as any other ezmlm-style
bounce rewriting, with maybe some utility for the relaying server to
validate a bounce... but not really.
SPF is only useful for the sender, and
On 2022-06-17 at 03:12:09 UTC-0400 (Fri, 17 Jun 2022 09:12:09 +0200)
Cyril - ImprovMX via mailop
is rumored to have said:
Correct me if I'm wrong, but from what I understood, using ARC, I can
craft
an email that came from joe.bi...@whitehouse.org - of course ignoring
all
the SPF/DKIM that
On 2022-06-17 at 09:12 +0200, Cyril - ImprovMX wrote:
> Obviously, this can't be it. One solution to this would be to set up
> a whitelist of services that you can rely on when you receive an ARC-
> Signed email, but this creates a two-way Internet and I prefer mine
> neutral, or at least
tldr; what ARC tries to address is already correctly handled by
DKIM/SPF/DMARC if used as designed.
IMHO ARC seems to be a solution to a problem that doesn't exist.
The message passes through your network and you make changes to it in the
process ? Sign it with DKIM on your edge/"last hop"
ARC, from my understanding, can not be accepted as a viable solution for
accepting email that were modified (and had their SPF/DKIM broken).
Correct me if I'm wrong, but from what I understood, using ARC, I can craft
an email that came from joe.bi...@whitehouse.org - of course ignoring all
the
Jeff, this is really interesting. Thanks for sharing. This answers a
lingering question for me as far as what practical applications there can
be for ARC in a context other than a mailing list.
Am I getting this right -- the way this would work is that another email
platform would sign/"seal" a
Folks,
As email passes thru our network, we make changes to the message. We may add
items to the header/footer or change links into "protected mode". Doing so
breaks Authentication.
Authenticated Received Chain (ARC). ARC helps preserve authentication results
across intermediaries.
Learn
61 matches
Mail list logo
