Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal

[Dave Crocker via mailop]

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
 > authorization.

Here's how NIST defines authentication 
:


"Verifying the identity of a user, process, or device, often as a 
prerequisite to allowing access to resources in an information system."


In the realm of the current discussion, what is authenticated is a 
domain name.  That is, the appearance of the domain name, within 
whichever bit of these specific techs is being discussed, is asserted 
and validated as having been authorized by the domain owner.  I think 
the specs are reasonably careful about defining this and sticking to it.


Within the NIST context, this might qualify as a kind of 'user', but 
resolving that 'might' would indeed get into quibbling.





I don't want to quibble on semantics, but I bring this up to point out 
that a key verifies a "process" (a mail server). 


Well... Not quite, I think.  SPF, perhaps, with its explicit registered 
server authorization.  But DKIM and I'd say DMARC (and ARC) are more 
oriented towards the email object that about a server.  (I'm hearing 
myself mumbling as I type this...)



The sending process is 
authorized if the key is registered,


Well, yeah, maybe.


passes challenge-response, and has 


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 to use the domain name. 
Just to be clear -- ie, pedantic -- all that magic is fully and 
completely outside the scope of any of these specs.




a good reputation in the receiver's system.


None of these specs and services say anything at all about 'reputation'. 
 That entire concept is entirely outside these specs.  The hope is that 
these specs produce activities that facilitate developing better/easier 
reputation assessment, but the specs themselves do not participate in 
this process.



If you are naive, you accept 
all messages from Google. If you aren't, you process all messages 
through complex reputation analysis. Or, you ask a reputation service, 
programmatically, just like today, but with true authentication.


yup.



What about system compromises? Same as today. You better keep your key 
private. If your key gets stolen, you can cancel all your registrations. 
That works today, but it depends on a TTL instead of being 
transactional. There are at most 100K ADMD's according to one poster. 
That's expensive but doable, and again, agencies could offer this 
service, because it wouldn't require a gaggle of people to accumulate 
the knowledge. You would know programmatically which ADMD's you 
registered with and how to deregister, because it is based on a public 
protocol.


Dave Crocker continues:
 > These are not intended to solve a more general need for
 > trust, but to lay a foundation for useful reputation analysis.

This assumes one has enough data.


What I meant by foundation is that these techs aid in developing a base 
of data that is noise free or at least has a lot less noise than when 
the domain name is unauthenticated.


d/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal

[Rob Nagler via mailop]

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 and respond to?

I actually don't see how this is any different from what we have now.

The problem is that you cannot automate reputation repairs. We recently had
to change IPs, and we got a couple of "bad" ones. To correct the problems
involved lots of emails, including to this list. If we assume there are
10,000 people on this list, that's 10,000 people who were disturbed by my
request to have my IP cleared. That's not quite an N^2 problem but close.
If there are only 1,000, it still doesn't matter. It's not an efficient way
to get problems fixed.

Dave Crocker writes similarly:
> 1. Please explain what you mean by a "public trust model".

Right now, someone can send a million messages to abuse@, postmaster@,
etc., and all those complaints are unauthenticated.

Switch to a cheaper, authenticated method that requires the sender to
connect to an out-of-band port with a valid public/private key pair. This
is expensive to generate, even in the cheapest way, so it would slow down
the senders who try to generate a key per complaint or message.

Require the sender to authenticate the first time via this port through a
challenge-reponse that includes a delay, say, to slow down registrations
further. As to the size of the database, 100K per ADMD is tiny in
comparison to the amount of spam sent to our servers.

Every message must be signed, or it goes through old style reputation
analysis, or it could be just rejected. The From: domain must point to the
public key just like ARC and DKIM.

Each sender has a reputation of some sort. The receiving server can choose
to initialize it at any level.

There could be bootstrap reputation services that receivers trust, similar
to the web of trust, to allow you to buy a higher reputation. Currently,
services like the SES and SendGrid do this in a way, but you can't transfer
reputation, because it is attached to their IPs.

If the message is rejected, there's a link in the message that says how to
correct the error. One of the errors is "low reputation", possibly with a
score.

To improve the reputation, the sender returns the message to the originator
or postpones it like it was greylisted.

The receiver is expected to operate in good faith as they are today to
accept and deliver mail.

When a user complains to the receiver, the key gets docked. No need to send
an FBL, although that could be still in place. Spam analysis can dock
reputation. Whatever the receiver wants, really, as long as they support
the reputation protocol to allow for complaints and ways to improve
reputation (web of trust).

The main difference with the current system is that a sender can check
their reputation quickly and easily. There might even be a way to check
reputation for any sender. A sender can issue a complaint against their key
with an explanation. This happens today, but it's a different out-of-band
protocol for each receiver, or you sign up for a service to fix it for you.

Perhaps this has been discussed and discarded. I am not a domain expert.
Please tear it apart.

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
> authorization.

Here's how NIST defines authentication
:

"Verifying the identity of a user, process, or device, often as a
prerequisite to allowing access to resources in an information system."

I don't want to quibble on semantics, but I bring this up to point out that
a key verifies a "process" (a mail server). The sending process is
authorized if the key is registered, passes challenge-response, and has a
good reputation in the receiver's system. If you are naive, you accept all
messages from Google. If you aren't, you process all messages through
complex reputation analysis. Or, you ask a reputation service,
programmatically, just like today, but with true authentication.

What about system compromises? Same as today. You better keep your key
private. If your key gets stolen, you can cancel all your registrations.
That works today, but it depends on a TTL instead of being transactional.
There are at most 100K ADMD's according to one poster. That's expensive but
doable, and again, agencies could offer this service, because it wouldn't
require a gaggle of people to accumulate the knowledge. You would know
programmatically which ADMD's you registered with and how to deregister,
because it is based on a public protocol.

Dave Crocker continues:
> These are not intended to solve a more general need for
> trust, but to lay a foundation for useful 

Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal

[Dave Crocker via mailop]

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. With a public trust 
model, it would be easy (and cheap) to communicate about these problems. 
(FBL's do not solve this problem either.) The big providers would bear 
the bulk of the cost, but it would be cheaper (guess) than the current 
solutions.


Why is the trust problem not solved by DMARC?



1. Please explain what you mean by a "public trust model".  I'm sure any 
of us could invent all sorts of reasonable and maybe interesting 
definitions, but I believe it is not an established term of technical 
art that is shared amongst us.  So what is your definition?  I'm looking 
for enough substance in the response to permit thinking about how to 
satisfy it, in practical terms, and to permit it to be useful


2. 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 
authorization.  These are not intended to solve a more general need for 
trust, but to lay a foundation for useful reputation analysis.  And 
example of why none of these can be sufficient for 'trust' is, of 
course, system compromise.



Thanks.

d/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal

[John Levine via mailop]

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 particular ADMD, the ADMD sends a
>response which requires you to show that you fixed the problem (whatever
>that is). ...

I think you underestimate the persistence and bad faith of spammers.  There
is for example a well known trick in which a spam business pretends to have
customers, and the response to each complaint is oh, we fired that bad
customer.

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 and respond to?

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Best practice for mailing list servers

[Mark Fletcher via mailop]

On Mon, Jun 20, 2022 at 11:47 AM Grant Taylor via mailop 
wrote:

> On 6/15/22 6:19 PM, Ángel via mailop wrote:
> > There is a fallback of connecting to the A record on port 25 if there
> > is no MX.
>
> When was the last time that anyone has seen the fall back to A record work?
>
> Just did a quick check on one of our mail servers and within the last hour
we've sent email via an A record.

Mark
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal

[Rob Nagler via mailop]

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 set
Return-Path and Errors-To on lists, which is what we did.

> Which was the point I was making: SPF does not cause problems with
> mailing lists, because they use their own domains in envelope sender
> addresses.

This subtle distinction was lost on me. Thank you for pointing that out.

When the big guns started enforcing DMARC/DKIM, we rewrote the From and the
envelope sender, solving both problems. Before that, we didn't have to.

> Because a "public trust system" is either impossible or at least
> resembles an impossibility.

I hope for the latter.

> There's no universal agreement on the specific outline of acceptable
> behavior regarding mail.

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 particular ADMD, the ADMD sends a
response which requires you to show that you fixed the problem (whatever
that is). This could server-to-server (e.g. unsubscribed user X) or
possibly require human intervention, but either way, there would be a
standard in place for identifying "you" and the meaning of "fix". If you
continued bad behavior, they don't have to trust you. The problem today is
that "you" is ill-defined and "fix" is even more poorly defined. While you
can't define everything, with DKIM and ARC, "you" is defined for
authorization but not authentication. A simple bidirectional
challenge-response protocol using these keys would be sufficient for this.
Publishing a "well-known" port for a "fix" server which allowed "you" to
respond appropriately would also be a relatively easy step. It's a bit like
greylisting in some sense, and maybe that approach (registration) could be
part of the trust system, too.

Thanks,
Rob
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal

[Dave Crocker via mailop]

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 came through, 
because he is asserting semantics for DKIM that, I believe, go far 
beyond what the specification provides.  He wrote:



The DKIM-Signature is an "ownership" thing, it's a message originator that
is saying
"associate this message to me".

Intermediaries don't want to take ownership of the message in that sense,
though there
are some mailing lists that do.


whereas the DKIM specification says:


DomainKeys Identified Mail (DKIM) permits a person, role, or
   organization to claim some responsibility for a message by
   associating a domain name [RFC1034] with the message [RFC5322], which
   they are authorized to use.


So he is taking "some" to mean quite a bit more than was intended or, I 
believe, than the language implies.(*)


Field-experience often differs considerably from the theory in a 
specification.  So it's possible that this aspect of DKIM needs 
revision, to provide a statement of semantics that adequately correspond 
to the real world.


But that should a matter of community discussion and agreement, of course.

d/

(*) It occurs to me that a different view is that, actually, email 
handlers don't carry any responsibility for the mail that transits 
through them. I'd find that an amusing stance and hope that it is not 
the community view.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal

[Alessandro Vesely via mailop]

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 organization to claim /somewhat less/ 
responsibility for a message.


People who should know have told me that the main use case for ARC is 
to deal with poor spam filtering on mailing lists. It is pretty common 
for lists to forward all the mail that arrives with a subscriber's 
address on the From: line with little if any further filtering. That 
works fine except when it doesn't, either a subscriber's account is 
compromised or more commonly someone else's address book got stolen 
and spam happens to put the subscriber's address on the From: line and 
the list on the To:.



It would be enough to have all subscribers set p=reject in order to prevent 
that kind of spoofing.  Unfortunately, one cannot set different policies for 
different recipients, and setting p=reject for all sounds hazardous.



ARC allows subsequent recipients to look back and do retroactive 
filtering. For most purposes it would be adequate if you know the 
sources that send list mail (large systems all do, small ones generally 
don't have very many) and allow mail with DMARC failures if the ARC 
chain says the DMARC was valid on the way in.



The same is true for plain forwarding.

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[*]).  If plain forwarding exceeds mailing list traffic, we could 
say the main use case is this.



Best
Ale
--

[*] https://mailarchive.ietf.org/arch/msg/dmarc/4luaOQ9ZOALnHkc7TPbeA5Yru7Y








___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Timeouts to Microsoft?

[Ken O'Driscoll via mailop]

They have two open incidents in their alert centre relating to access to 
Exchange Online and Microsoft 365.

As an EU based user, I can't say I've experienced anything, nor have any 
clients reported problems to me but most of them are only waking up now so...

Ken.

> -Original Message-
> From: mailop  On Behalf Of Stefano Bagnara
> via mailop
> Sent: Tuesday 21 June 2022 11:08
> To: mailop 
> Subject: [mailop] Timeouts to Microsoft?
> 
> Hi,
> 
> Since 4 hours we are experiencing slowness (e.g. connections timing out,
> very slow responses), to Microsoft both sending to their SMTP and
> reading via IMAP, from europe (checked from 4 different datacenters in
> europe).
> 
> Do you see the same?
> 
> --
> Stefano Bagnara
> Apache James/jDKIM/jSPF
> VOXmail/Mosaico.io/VoidLabs
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal

[Alessandro Vesely via mailop]

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, not headers addition.

But worst one from that RFC? Why? Because it doesn't fit other (later) RFC's? 
Is it not sign, that later RFCs are broken (ignoring something, not finished, 
etc...)?



Just how that section is written.  You may have noted that in the *List* 
subsection it says "forwarding (this subsection)".  Is that a leftover from 
when the subsection was named differently?  (Curiously, that sentence is 
repeated exactly like, including the reference to Section 3.9.1, in Section 4.4.)


Only a few features are covered.  Sketchily.  The term *forwarding* is actually 
left undefined.




That's right.  In the upcoming version of the standard that sentence is removed:
https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-rfc5321bis#section-3.4.2 


I mean new standard, not update of the existing...

Anyway, what removing that sentence is try to solve? DMARC broken by MLs? Here 
is already broken DMARC+SPF (not need to discuss it). Valid DMARC thus require 
valid (and aligned) DKIM. But DKIM can become invalid not only by modifying 
message body, but by modifying signed headers and/or even by adding oversigned 
headers (eg. the List-* headers).


Or goal is to allow rewrite 5322.From header? As ML is/was not author (who 
wrote) of the message, thus 5322.From: rewrite will simple break another RFC.


I hope, that you (or author of that change) know, that solving one break by 
another break is wrong way... This problem (DMARC+ML) cannot be solved by one 
part of chain. Only if they all (SMTP+DKIM+DMARC+...) will go together, they 
can produce something useful...



Personally, I find that this list, for example, works very well.  The MTA I use 
implements most current standards and they fit together well.


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.



I can imagine the ARC can solve that problem, but as start of this thread 
shows, it can be misused too...



To implement ARC you need a global view of all MTAs.  Only a few giants can 
afford it.  Small operators can implement just the sealing part, if they 
forward to Microsoft of Google.


Certainly, it's not a solution for mailing lists, unless /all/ subscribers 
belong to one of those two providers.



Best
Ale
--




___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Timeouts to Microsoft?

[Stefano Bagnara via mailop]

Hi,

Since 4 hours we are experiencing slowness (e.g. connections timing
out, very slow responses), to Microsoft both sending to their SMTP and
reading via IMAP, from europe (checked from 4 different datacenters in
europe).

Do you see the same?

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal

[John Levine via mailop]

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 message.

People who should know have told me that the main use case for ARC is
to deal with poor spam filtering on mailing lists. It is pretty common
for lists to forward all the mail that arrives with a subscriber's
address on the From: line with little if any further filtering. That
works fine except when it doesn't, either a subscriber's account is
compromised or more commonly someone else's address book got stolen
and spam happens to put the subscriber's address on the From: line and
the list on the To:.

ARC allows subsequent recipients to look back and do retroactive
filtering. For most purposes it would be adequate if you know the
sources that send list mail (large systems all do, small ones generally
don't have very many) and allow mail with DMARC failures if the ARC
chain says the DMARC was valid on the way in.

R's,
John
-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal

[Dave Crocker via mailop]

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 address of a person or other entity who
 administers the list. However, in this case, the message header 
section
 (RFC 5322 [4]) MUST be left unchanged; in particular, the "From" 
field of

 the header section is unaffected.



Section 3.9 is perhaps the worst one in that document.  By that wording, 
the addition of /any/ header field is forbidden, including List-*.



RFC5321 is currently under revision, in the IETF's emailcore working 
group.  I'd recommend your offering comments to the working group.


 https://datatracker.ietf.org/doc/charter-ietf-emailcore/

d/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal

[Bill Cole via mailop]

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 envelope from at that 
time.

They were managing bounce addresses.


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."


To test my conjecture, I downloaded mailman-2.1.15 (2012-06-15) and 
didn't

find any "via" handling. I picked mailman-2.1.19 (2015-02-28), and it
handles DMARC, but it seems to wrap messages in another message, and
doesn't do From rewriting (cursory glance).


In any version, it never sends a list message out with the same envelope 
sender that it arrived with. The same is true of majordomo, LISTSERV, 
ezmlm, Lyris, and every other ML package I've used in the past 30 years 
and I expect also of those I've not used.


Which was the point I was making: SPF does not cause problems with 
mailing lists, because they use their own domains in envelope sender 
addresses.



I looked at mailop's history, and it
was a simple reflector in 2018, less than 5 years ago.


Not true. See Graeme Fowler's message.


I apologize if I slighted Graeme or anybody else with the word "simple
reflector".

I meant that there wasn't any From rewriting 5 years ago. I would like 
to

change that to 10 years ago, but it's certainly not 20.


True for this list, and broadly true unless you count the NP-complete 
language used in sendmail.cf since at least v5 which does nothing but 
rewrite addresses... :)


And it is generally true that software designed to accept messages via 
SMTP at a public list address and redistribute them to a mailing list 
mostly didn't mess with the From header address until meaningful DMARC 
enforcement reared it's ugly head ~5 years ago.




[...]
There arguably *IS* an issue with still running Mailman 2.x in 2022, 
but

that's a very special case of hard-to-upgrade software.

This was my main point, really. Mail is becoming much more complicated 
to

manage and to implement.


True. In the specific case of Mailman the upgrade impediment has nothing 
to do with mail per se, but the general point is valid. It is especially 
painful to stand up new mail systems that have to talk directly to the 
world.



Add to this "reputation" and other opaque
barriers, which are just "hard-to-upgrade" peerings. The standards are
making things more complicated (and confusing) while skirting the 
primary

issue which is a public trust system.


Because a "public trust system" is either impossible or at least 
resembles an impossibility.


There's no universal agreement on the specific outline of acceptable 
behavior regarding mail. So while we have a somewhat working toolset for 
authentication grounded in the single-root DNSSEC tree and a 
quasi-consensus on X.509 roots, there's no consensus on the shape of any 
authorization layer.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal

[Slavko via mailop]

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? Because it doesn't fit other (later) 
RFC's? Is it not sign, that later RFCs are broken (ignoring something, 
not finished, etc...)?


That's right.  In the upcoming version of the standard that sentence is 
removed:
https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-rfc5321bis#section-3.4.2 


I mean new standard, not update of the existing...

Anyway, what removing that sentence is try to solve? DMARC broken by 
MLs? Here is already broken DMARC+SPF (not need to discuss it). Valid 
DMARC thus require valid (and aligned) DKIM. But DKIM can become invalid 
not only by modifying message body, but by modifying signed headers 
and/or even by adding oversigned headers (eg. the List-* headers).


Or goal is to allow rewrite 5322.From header? As ML is/was not author 
(who wrote) of the message, thus 5322.From: rewrite will simple break 
another RFC.


I hope, that you (or author of that change) know, that solving one break 
by another break is wrong way... This problem (DMARC+ML) cannot be 
solved by one part of chain. Only if they all (SMTP+DKIM+DMARC+...) will 
go together, they can produce something useful...


I can imagine the ARC can solve that problem, but as start of this 
thread shows, it can be missused too...


Perhaps better solution can be to not remove that sentence, but change 
it from MUST to SHOULD (and mention that it requires good reason). Then 
we can move discussion from "why (not) break RFC" to "what is good 
reason" (as variant of "my server, my rules")...


regards

--
Slavko
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] OVH contact required - 54.38.34.203 - vps-28239cc9.vps.ovh.net

[Atro Tossavainen via mailop]

Cher M CARON

> Sorry but I represent OVH email team (not abuse), I have no power and 
> visibility on stuff out our email offer perimeter.

This is understood.

> As I say in private, the abuse form https://www.ovh.com/abuse/#!/ permit to 
> report spam problems. It ensure to abuse team enough information to check and 
> block.

If a ticket system does not allow email input with similar outcomes
it has to be considered as broken.

I had one that did (Request Tracker v2.x) at a former workplace ever
since September 11, 2001 (but I disclaim responsibility for the follow-up
effects later that day), and I was late to the game when I installed it
then.

> Moreover you will receive a ticket number and a notification when it’s close.

This should be possible irrespective of whether tickets are opened by
webform, email, phoning in, or other channels I didn't even think to
mention yet.

> To be honest I follow the Dima case but not your case. If I start to handle 
> abuse cases out of normal process it will be the mess…

It is true. However, OVH appears to have somewhat of a systemic problem,
and any amount of Mailop'ers writing to you or to Romain does not solve
that. The normal process needs to be improved quite a bit.

Amicalement,
-- 
Atro Tossavainen, Founder, Partner
Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635)
Tallinn, Estonia
tel. +372-5883-4269, http://www.koliloks.eu/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal

[Alessandro Vesely via mailop]

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:


    "DomainKeys Identified Mail (DKIM) permits a person, role, or
    organization to claim some responsibility for a message by
    associating a domain name [RFC1034] with the message [RFC5322], which
    they are authorized to use."

"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 message.



Best
Ale
--






___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal

[Alessandro Vesely via mailop]

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 signature still validates upon undoing 
their changes.


If my domain had DMARC record with p=reject instead of p=none, you would 
receive a message with: "From: Jaroslaw Rafa via mailop 
". You can find a lot of such examples in the messages 
from other people on this list. Other mailing lists perform similar 
rewriting.


Well, looks like I didn't look at the headers actually :) This list rewrites 
"From:" address to the above form even that I don't have p=reject. It 
actually seems to rewrite all sender addresses...


So you must use some special filtering in your MUA to see my message as 
"From: Jaroslaw Rafa ", because it just doesn't look so.



It is done by the MTA.  Documented here:
http://www.tana.it/sw/zdkimfilter/zdkimfilter.html#mlmtrans


I don't want to talk here about specific home-crafted solutions that revert 
changes made by mailing lists. I want to talk just about ordinary, 
"out-of-the-box" MUAs and MTAs.


Yes, not being "ordinary" is the most common objection to that method of 
undoing MLML transformations.  However, ARC is not ordinary either, and From: 
munging itself only became ordinary quite recently.



Best
Ale
--





___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] OVH contact required - 54.38.34.203 - vps-28239cc9.vps.ovh.net

[Pierre-Edouard Caron via mailop]

Hello Hans-Martin,

Sorry but I represent OVH email team (not abuse), I have no power and 
visibility on stuff out our email offer perimeter.

As I say in private, the abuse form https://www.ovh.com/abuse/#!/ permit to 
report spam problems. It ensure to abuse team enough information to check and 
block.
Moreover you will receive a ticket number and a notification when it’s close.

To be honest I follow the Dima case but not your case. If I start to handle 
abuse cases out of normal process it will be the mess…
I ask abuse this morning and any report have been done for the IPs you mention.

Regards,

Pierre-Edouard Caron
Devops Email team
OVHCloud

De : mailop  De la part de Hans-Martin Mosner via 
mailop
Envoyé : lundi 20 juin 2022 07:35
À : mailop@mailop.org
Objet : Re: [mailop] OVH contact required - 54.38.34.203 - 
vps-28239cc9.vps.ovh.net

Am 15.06.22 um 10:40 schrieb Pierre-Edouard Caron via mailop:
I’m not aware about their process but I know that they wait multiples reports 
before to block.
They are improving the pipeline to give more notifications that the report have 
been handle.


I've reported a list of a few dozen IPs at OVH that are clearly used by one 
snowshoe spammer to Pierre-Edouard and to abuse@OVH, but to no effect.

Apparently "improving the pipeline" does not involve "working on the issues", 
maybe "deciding on a color scheme for abuse reporting web form" is eating up 
all of the committe meeting time? :-)

Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal

[Alessandro Vesely via mailop]

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 the message.


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 address of a person or other entity who
 administers the list. However, in this case, the message header section
 (RFC 5322 [4]) MUST be left unchanged; in particular, the "From" field of
 the header section is unaffected.



Section 3.9 is perhaps the worst one in that document.  By that wording, the 
addition of /any/ header field is forbidden, including List-*.



[...] Or, as often happens, we will get another RFC, which will try to solve
these conflicts (and IMO introduces another).


That's right.  In the upcoming version of the standard that sentence is removed:
https://datatracker.ietf.org/doc/html/draft-ietf-emailcore-rfc5321bis#section-3.4.2


Best
Ale
--






___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] No MX? use A/AAAA

[Stuart Henderson via mailop]

On 2022/06/20 15:39, Jarland Donnell via mailop wrote:
> I've seen it work but frankly, I don't bother with it anymore. No MX for
> sender or recipient, I don't send it. This rspamd module right here:
> https://rspamd.com/doc/modules/mx_check.html

That is not what mx_check does at all. It looks for MX _or A_ records
and (if not already cached) tries connecting to them to see if something
answers on port 25.

https://github.com/rspamd/rspamd/blob/master/src/plugins/lua/mx_check.lua#L193
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] OVH contact required - 54.38.34.203 - vps-28239cc9.vps.ovh.net

[Hans-Martin Mosner via mailop]

Am 20.06.22 um 20:25 schrieb Hans-Martin Mosner via mailop:

Am 20.06.22 um 07:35 schrieb Hans-Martin Mosner via mailop:
I've reported a list of a few dozen IPs at OVH that are clearly used by one snowshoe spammer to Pierre-Edouard and to 
abuse@OVH, but to no effect.


Today I see an effect, very nice. All of those (including the ones that I didn't report yet because I only saw them 
later) are gone. Thumbs up! 


Spoke too early. Looks like the spammer just removed recipients from their list whose host isn't reachable (because they 
are in our IP block list). Still sending to other recipients, though, so apparently not terminated by OVH.


So thumbs down again. And sorry for self-responses, I'll stop now.

Cheers,
Hans-Martin

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop