Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Dave Crocker via mailop]

On 5/18/2024 2:12 PM, Gellner, Oliver via mailop wrote:

Changing the existing DKIM specification is probably a big challenge.


Yes, but it can be done as a separate specification that is classed as 
an 'update' to the DKIM spec.


fwiw, I've heard rumors of some industry folk wanting to produce "DKIM 
2", but the rumors have carried no details to indicate what the 
substance might be.




Another approach could be to update the wip BIMI specification with a
statement that a DMARC pass must be ignored if it is solely based on
valid DKIM signatures with length attributes.


Please no.  There has been some tendency to effect a change in an 
underlying specification by adding a constraint onto a specification 
that uses the underlying one.


The result has been basic modifications to email, without changing basic 
specifications.


Note, for example, that DMARC has broken the From: field, so it now 
serves as what the Sender: field was designed for.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Dave Crocker via mailop]

On 5/17/2024 7:12 AM, Taavi Eomäe via mailop wrote:
Although some of these dangers have been known for a while (some parts 
are even described in the RFC itself), things like the threat 
landscape, our approach and the extent to which this can be abused 
have changed. In our opinion previously suggested and (rarely) 
implemented mitigations do not reduce these risks sufficiently.


We hope that with some cooperation from mail operators improved 
defense measures can be implemented to strengthen DKIM for everyone. 



As I recall, the original intent was to permit successful use of DKIM in 
spite of mailing lists' addition of footer text.


I think the view of damage from DKIM failure and/or abuse was rather 
more benign than suits today's email world.


It wasn't a great feature at the time and now it is worse than that.

Seems like the right approach is to seek community-wide pressure to 
deprecate it.  First through operational pressure and then with an 
update to the spec.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [mailop] (Mis)use of DKIM's length tag and it's impact on DMARC and BIMI

[Dave Crocker via mailop]

On 5/17/2024 7:12 AM, Taavi Eomäe via mailop wrote:
Although some of these dangers have been known for a while (some parts 
are even described in the RFC itself), things like the threat 
landscape, our approach and the extent to which this can be abused 
have changed. In our opinion previously suggested and (rarely) 
implemented mitigations do not reduce these risks sufficiently.


We hope that with some cooperation from mail operators improved 
defense measures can be implemented to strengthen DKIM for everyone. 



As I recall, the original intent was to permit successful use of DKIM in 
spite of mailing lists' addition of footer text.


I think the view of damage from DKIM failure and/or abuse was rather 
more benign than suits today's email world.


It wasn't a great feature at the time and now it is worse than that.

Seems like the right approach is to seek community-wide pressure to 
deprecate it.  First through operational pressure and then with an 
update to the spec.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [mailop] Doesn't ARC substitute DKIM at Gmail inbound?

[Dave Crocker via mailop]

On 5/5/2024 9:49 AM, Andrew C Aitchison via mailop wrote:
DKIM proves that you did send it. 



No it doesn't.

But that certainly is a common misconception about DKIM.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [mailop] Google Mail rejects forwarded email despite `~all` in SPF

[Dave Crocker via mailop]

But In this case, envelope sender domain is different from domain in 
header From: and then SPF checks don't apply to DMARC.


So, if you want to have proper DKIM, you must set From: to your domain 
and DKIM-sign it.



To be finicky: DKIM does not care what domain is used in its d= 
parameter.  The alignment with the From: domain is a DMARC requirement, 
not DKIM.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [mailop] mailop and DKIM signatures

[Dave Crocker via mailop]

On 3/21/2024 3:47 AM, Alessandro Vesely wrote:

Mailing lists modify messages in a de-facto standard way.


actually, they don't.  or rather, there is more than one de-facto set of 
modifications and therefore efforts to reverse the modifications is in 
the realm of heuristics, which means sometimes they will work and 
sometimes they won't.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [mailop] mailop and DKIM signatures

[Dave Crocker via mailop]

On 3/16/2024 1:31 PM, Slavko via mailop wrote:

And the same RCF clearly suggests to leave other (even invalid)
signatures untouched.



Which text in RFC 6376 says that?

Perhaps you are thinking of Section 6.1 which includes:


INFORMATIVE NOTE: The rationale of this requirement is to permit
   messages that have invalid signatures but also a valid signature
   to work.  For example, a mailing list exploder might opt to leave
   the original submitter signature in place even though the exploder
   knows that it is modifying the message in some way that will break
   that signature, and the exploder inserts its own signature.  In
   this case, the message should succeed even in the presence of the
   known-broken signature.


which notes it might be done, but certainly is not advice to do it.  
(Also note the paragraph is informative rather than normative.  Also 
note the reference to mailing lists, as being discussed here.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] mailop and DKIM signatures

[Dave Crocker via mailop]

DKIM policy is
reject or quarantine.


That's DMARC, not DKIM.

DKIM does a signature.  DMARC uses it (and/or SPF).

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] % in SRS ?

[Dave Crocker via mailop]

On 3/8/2024 9:21 AM, Bill Cole via mailop wrote:

Yes: it is an old routing character

As such, some sites may misinterpret it in ways that are NOT 
appropriate for SRS.


oh?

SRS is not a standard.  If there are sites trying to do automated 
interpretation -- other than the site that put the string there -- 
that's the problem, not the choice of a semantic character.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [mailop] % in SRS ?

[Dave Crocker via mailop]

On 3/8/2024 9:21 AM, Bill Cole via mailop wrote:

Yes: it is an old routing character

As such, some sites may misinterpret it in ways that are NOT 
appropriate for SRS.


oh?

SRS is not a standard.  If there are sites trying to do automated 
interpretation -- other than the site that put the string there -- 
that's the problem, not the choice of a semantic character.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [mailop] % in SRS ?

[Dave Crocker via mailop]

On 3/8/2024 9:07 AM, Julian Bradfield via mailop wrote:

Is there any reason not to use the old routing character '%' instead?



Well, that's certainly a bit of ancient history. Fwiw, here's some 
background on it:


I chose % for use in CSNet mostly because of its established postal use 
IRL to mean "in care of", as well as to use a character that was not yet 
a 'special' for any (or at least most) operating system command interfaces.


Note that @, for Arpanet mail, and !, for UUCP, were already taken.  So 
the range of choices was limited in 1979...


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Filter out emoji from email adresses

[Dave Crocker via mailop]

On 3/6/2024 10:13 AM, Bill Cole via mailop wrote:
support for SMTPUTF8 *in MTAs operating as MXs* is not widespread 
enough to be useful except



Email has a long history of very poor compliance, coupled with recipient 
demands that sender-side problems be dealt with using receiver-side 
changes.


The upgrade to more than US-ASCII started in 1990, for email content and 
while MIME solved that within a couple of years, improvements for the 
header and addressing have continued to be a problem.


By way of example, the 'Universal Acceptance' effort has been underway 
for a very long time, and yet a thread like this one here continues to 
happen.


   Universal Acceptance (UA) - ICANN <#>

    https://www.icann.org/ua 

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Mailop "best practices" - clarifications please

[Dave Crocker via mailop]

On 3/4/2024 4:50 AM, Andy Smith via mailop wrote:

but I don't relish trying to navigate inevitable issues
of disagreement between us all on what is actually best practice


Perhaps when there are significant constituencies for competing choices, 
merely add a comment about it, explaining the nature of the choices, the 
tradeoffs they have, and why there are preferences for each.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] One click unsubscribe in mailing list messages

[Dave Crocker via mailop]

On 2/24/2024 5:25 PM, Philip Paeps via mailop wrote:
On the whole, I think not meddling with the body (and not breaking 
DKIM) provides an improved mailing list experience.  We don't have to 
rewrite the From: header, and "reply" works the way the poster 
intends.  Neither the mailing list software nor the recipient has to 
guess.


Sounds like a win.

Generally, whatever is typically put in the footer can reasonably be 
move to a header field, although of course that means users will 
typically not automatically have it presented to them.


A different issue is that it tends to be helpful for the Subject field 
to show that a mailing list is involved, though that will typically 
break DKIM...


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [mailop] Opinions on what qualifies as a "false positive" RBL listing that should be fixed?

[Dave Crocker via mailop]

On 2/15/2024 1:36 PM, Robert L Mathews via mailop wrote:

not using COI and hitting spamtraps as a result, for messages that in other 
respects are wanted by recipients and transactional


Not using COI, as well as hitting spamtraps are both solid, affirmative 
indications of spam.  Full stop.

You want to mitigate that assessment.  Don't.  Because it doesn't mitigate it.

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Is forwarding to Gmail basically dead?

[Dave Crocker via mailop]

On 2/12/2024 7:13 PM, Mark Milhollan via mailop wrote:

On Mon, 12 Feb 2024, Dave Crocker wrote:

Certificates are not magic symbols of safety.


I never said they were.  I said, paraphrasing though I see I should 
have been explicit, that Google could increase the number of people 
using S/MIME though not any additional MUAs since theirs already has 
S/MIME support though different. 



Right.  Except almost certainly wrong.

Just making certs easier to get will increase S/MIME use.  This ignores 
a collection of other usability and management issues that represent 
significant barriers to adoption and use.  And that's just with S/MIME 
itself, nevermind the integration of its use into a helpful reception 
management function.


My point is that serious efforts at achieving real efficacy that is 
better than what we get now will require considerably wider and deeper 
design thinking that just making certs easier.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [mailop] Is forwarding to Gmail basically dead?

[Dave Crocker via mailop]

On 2/12/2024 7:16 PM, John Levine via mailop wrote:

Right now if
you get a message from Gmail or Yahoo with a valid DKIM signature, you
can be quite confident that it came from whichever Gmail or Yahoo user
is in the From header.



By way of using this as an example of the need for larger systems 
thinking, the assessment that it came from such a user is not in the 
actual DKIM specification.  DKIM's semantic is dramatically less 
ambitious than that.  It only says that the signer had 'some' 
responsibility for (handling) the message.  Very modest semantic, indeed.


However operational practice makes it a reasonable assessment, at least 
for mail signed by some platforms.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Is forwarding to Gmail basically dead?

[Dave Crocker via mailop]

On 2/12/2024 4:37 PM, Mark Milhollan via mailop wrote:

On Mon, 12 Feb 2024, Dave Crocker wrote:


1. S/MIME has been around for 25 years. While it has gained
   respectable amounts of implementation in MUAs, it has achieved use
   only in specialized environments.


Google could greatly accelerate its uptake by automatically providing 
every freemail account with a certificate (DV cert style, i.e., 
without a fullname) and adding it and a signature to every message, 
and an indicator on messages received. 



Certificates are not magic symbols of safety.

Please think through the maintenance and use issues, end-to-end, 
including how to handle new, legitimate folk you've never met before but 
-- it will turn out -- you don't mind getting an unsolicited message from.


Of all of email's problem's, the most intractable is the widespread and 
continuing insistence that its problems can be solved simply.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [mailop] Is forwarding to Gmail basically dead?

[Dave Crocker via mailop]

On 2/9/2024 1:16 AM, Taavi Eomäe via mailop wrote:
My hope is that at some point we would be able to do "BIMI" with just 
S/MIME signed mail at some point. Seems like a good combination.



1. S/MIME has been around for 25 years.  While it has gained
   respectable amounts of implementation in MUAs, it has achieved use
   only in specialized environments.  Any technology with a record that
   poor should be treated extremely skeptically, when considering
   future use.
2. BIMI is a marketing protocol, for promoting brand logos.  What
   anti-abuse benefit do you believe accrues with its use, and how
   exactly do you believe it will achieve that?

d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Is forwarding to Gmail basically dead?

[Dave Crocker via mailop]

On 2/9/2024 6:50 AM, Scott Mutter via mailop wrote:
I think the issue with SPF and DKIM is that it's becoming trivial for 
ALL email to have SPF and DKIM that pass muster.  At which point, 
you're right back where you started.



At the start, we had no way to assess email streams.  Good mixed with 
bad in ways that made it almost impossible to distinguish them.


With SPF and DKIM, receivers have relatively 'noise free' message 
flows.  A flow that has an authenticated identifier associated with it 
is highly likely to actually be email associated with the owner of that 
identifier.  This permits relatively noise-free analysis of their 
behavior, without concern that some other factor -- like someone else 
using the identifier -- is injecting email into that flow.


In fact, it is /good/ that bad actors also use these technologies, since 
it makes it much easier to identify their crappy email.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [mailop] Guide for setting up a mail server ?

[Dave Crocker via mailop]

On 7/14/2023 11:21 AM, Grant Taylor via mailop wrote:
Suggest you might consider changing the topic, if you want to argue 
the various nuances and complexities of SPF/DKIM/DMARC etc..?


And break existing threading and avoid any ignore thread filters that 
people have put in place?


That seems like people changing email addresses to get around filters. 



This is exactly the type of breakage, caused by From field re-writing, 
that has been entirely ignored, in spite of being cited with some 
frequency.  It is, to coin a phrase, an inconvenient truth.



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Guide for setting up a mail server ?

[Dave Crocker via mailop]

On 7/14/2023 11:20 AM, Paul Smith wrote:


On 14 July 2023 18:24:45 Dave Crocker via mailop  
wrote:



We need to 'encourage' people to run their own mail servers, not scare
them away..


We also need to encourage people to do all the servicing for their car,
to build their own house, and to grow their own food.

Or we might take a somewhat more modern view of life and deal
pragmatically with the realities of the division of labor.



But if someone *wants* to set up a mail server, we shouldn't put them 
off unnecessarily.


Or would you put someone off growing vegetables in their garden as well?

If someone says "I want to receive email", then suggesting they set up 
their own mail server may be inappropriate, but that's not the case here.



The use of 'encourage', that I was responding to, was not in a tone that 
had to do with an individual person's preferences, but about pressing 
for a professional bias. In the context of this discussion, it frankly 
had a tone of social pressure, IMO.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Guide for setting up a mail server ?

[Dave Crocker via mailop]

We need to 'encourage' people to run their own mail servers, not scare 
them away.. 


We also need to encourage people to do all the servicing for their car, 
to build their own house, and to grow their own food.


Or we might take a somewhat more modern view of life and deal 
pragmatically with the realities of the division of labor.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [mailop] Guide for setting up a mail server ?

[Dave Crocker via mailop]

On 7/11/2023 2:54 AM, Slavko via mailop wrote:

Setup and get it working is not different than other services,
not more easy nor more hard, just different. It requires to learn
how to setup particular SW as in other services. What i see as
more hard with email is:

+ it is not one protocol (SMTP and IMAP/POP)
+ it is not one SMTP purpose (MTA/Submission)
+ terminology is not clear (how many terms eg. for return-path, relay, etc)
+ it is very flexible, choose proper topology is not easy without some 
experiences
+ many roles, which one MTA can do
+ too many RFCs describing email, and some of them are not well cooperative
+ outdated or incomplete/wrong guides
+ lack of (open source) tools to work with eg. MIME mails



In case this helps:

RFC 5598: Internet Mail Architecture

 https://www.rfc-editor.org/rfc/rfc5598 



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] SendGrid is deleting your mail

[Dave Crocker via mailop]

On 6/23/2023 9:13 PM, Al Iverson via mailop wrote:

What if we just got to the heart of the matter and admitted that
greylisting is useless 2023?



This prompts wondering whether it's time for the email anti-abuse 
community to have a discussion about mechanisms that used to be useful 
but are no longer worth the effort (or that might actually be 
counter-productive.)


The likely benefits will be simplification on the technical and 
operations side, and possibly better outcomes.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@dcrocker@mastodon.social

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

Re: [mailop] "header is missing" at Gmail

[Dave Crocker via mailop]

On 11/8/2022 2:03 PM, Mary via mailop wrote:

've seen this before, when the header above the From header is broken:

Authentication-Results: server;
dkim=blah reason="blah";
From: "Valid"
To: mailop


The parser thinks that the From: header is part of the previous header, thus 
ignoring it and ending with a missing header error.


On the offchance anyone reading this thread misses the basic point -- 
and no, I don't expect that include most or possibly any of... you:  The 
From field, here, is in fact part of the A-R field.  Because 'from' is 

indented, it IS a continuation of the preceding field.


On 11/8/2022 3:11 PM, Brandon Long via mailop wrote:

Another one I've seen is an extra newline which ends the headers, ie:

Subject: foo
To: b...@example.net

From: campa...@example.org


And again, to state the obvious, just to document it explicit;y in this 
thread:  The blank line means that the From field is in the body, not 
the header.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:dcrocker@mastodon.social
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DMARC Stockholm syndrome, Reject vs spam folders

[Dave Crocker via mailop]

On 9/19/2022 11:59 AM, Brandon Long wrote:
On Sat, Sep 17, 2022 at 11:10 AM Dave Crocker via mailop 
 wrote:


On 9/16/2022 7:35 PM, Brandon Long via mailop wrote:

> So, while AOL & Yahoo were the vanguard for mass consumer
providers, the problems were already being experienced by many
corporate domains before that, and even more since.

The issue is not that the abuse was/is not real but that the
method of responding to it was chosen in a manner that
externalized the problem to innocent third-parties, breaking what
they had been doing for 40 years.

It would be good not to be cavalier about this, just because those
experiencing the collateral damage are not our users.

Every spam false positive is collateral damage experienced by both the 
sender and receiver.  And every spam false negative is another nail in 
email's coffin.  Is that not also collateral damage to "not our 
users", especially
since this thread is spawned from the oligopoly discussion as 
complaints from small senders?


Brandon, it is cavalier to start with cliches and stop with them.  
Especially with cliches this generic.


The imperfections of basic spam filtering technologies do not change 
email semantics.  Nor do they have a knock-on effect on services and 
uses that have no contact with the platform running the filtering.


Expanded use of DMARC creates both of these collateral damages.



Aren't RBL's based on the power of collateral damage?


That's a nicely cryptic reference. I have no immediate guess what you 
mean.  Please explain.



DMARC was not new in its externalization.   Maybe the forced change to 
semantics makes it different in some way, or who was hit was 
different, sure.


I believe that it /was/ new in its externalizations.  Since you believe 
otherwise, please provide details.



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] ARC field experience (was: Re: DMARC Stockholm syndrome, Reject vs spam folders)

[Dave Crocker via mailop]

On 9/19/2022 8:07 AM, Alessandro Vesely via mailop wrote:
ARC is the authentication of choice in this case because, being 
devised for this task, it is supposedly straightforward to configure 
for it, whereas whitelisting after SPF or DKIM smells like a hack. 


ARC is moderately complicated technology.  I know it's header fields are 
showing up, but nothing about the state of real-world receiver-side 
processing.


And ARC has been around long enough that it is probably worth asking for 
reports on style of use and degree of efficacy.


d/

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

Re: [mailop] DMARC Stockholm syndrome, Reject vs spam folders

[Dave Crocker via mailop]

On 9/17/2022 8:12 AM, Jim Popovitch via mailop wrote:

and DMARC was to fix what DKIM broke,
and DKIM was to fix what SPF broke, and SPF was to fix (what was SPF
suppose to fix, oh yeah... provider greed and irresponsibility).


DKIM didn't break anything.  It has limitations, as do all technologies.

DMARC did break effective third-party handling.

And providers don't create spam.  So your cleverness wasn't.

d/


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

Re: [mailop] DMARC Stockholm syndrome, Reject vs spam folders

[Dave Crocker via mailop]

On 9/16/2022 7:35 PM, Brandon Long via mailop wrote:
For 30 years, we allowed mailing lists to modify messages and take 
partial "ownership" of them (the mailing list gets the


 * Small factual nit:  Networked email was 50 years old, last year. 
   Mailing lists appeared almost immediately after that. Say 45 years ago.
 * "Allowed" establishes an odd and false view of Internet application
   development and use, since there was never any authority forcing
   creation or use of any Internet app.  The term is meaningful only if
   there had been such an authority. Saying "allowed" for a process
   that was and remains entirely community driven does not make much
   sense, though it arguably sets the stage for the more-recent
   experience of change imposed by operators with extraordinary market
   leverage.  As we have seen.
 * "Taking partial ownership" is odd and ambiguous phrasing.  So let's
   be straightforward and specific:
 o An author posts a message to a mailing list address.  The author
   and the originating platform "own" the message.
 o The message is delivered to that address.
 o The mailing list formulates a brand new message, based on the
   one it received, but changed in whatever ways the mailing list
   feels like doing.  In the same sense as such control and choice
   applied to the author originally formulating the message they
   posted.
 o The mailing list 'owns' all of its choices and it owns the
   resulting message.
 o In the interest of the a higher-level membership overlay
   semantic, the mailing list typically will post a message that
   sustains a participant sense of and end-to-end -- ie, author to
   reader -- integration. That is, it stitches together two,
   independent email posting/delivery segments, to produce a
   seamless user experience.  The author-created rfc5322.From
   header field has pretty much always been part of that choice.
 * The mailing list posts this new message, typically with and address
   related to the mailing list in the rfc5321.Mail From command, but
   not always.

Let's stress the key point a bit more:

 * The mailing list fully 'owns' the message it posts.
 * The mailing list might or might not choose to facilitate a
   participant experience (a version of UX) that creates a sense of
   integration and utility that connects the author posting with the
   mailing list posting.



bounces), without
modifying who the message was "from".  When digital signatures were 
introduced and then linking them to the sender, it made that untenable...


Again, let's be very careful here.

 * Digital signatures did not create a problem.  As already noted,
   DKIM's d= was specified so that the linked domain name did not have
   to be related to any other domain name or email address in the
   message. And a DKIM failure was explicit that the result must be the
   same as having no DKIM present.
 * DMARC created the linkage to the From: header field.  When DMARC was
   created, it was clear it would create a problem for third-party
   uses, such as mailing list. However DMARC development was explicitly
   for a business-to-consumer use that would not involve such third
   parties.
 * Much later, some very large email platforms unilaterally chose to
   expand DMARC's use to consumer-to-consumer and therefore,
   inevitably, created the collateral damage of breaking third-party
   use that had been in place for 40 years.


but the reason we added the signature and linkage was because of bad 
actors, and the number of "we always did it this way" things that have 
fallen to our fight with bad actors has been quite large.


Forgive me, but a version of that line of comment has been quite common 
in some email professional circles.  It primarily serves to cut short 
serious discussion.  It's much too facile, and typically ignores 
unintended consequences.  And as formulated above, I think it's probably 
wrong.


 * Specifically, anti-abuse work certainly has made operating an email
   platform a lot harder.  However, the effect on end-users has
   generally been hassle, but no alteration in email semantics or use.
 * DMARC changed that.  The unilateral decision by email platform
   operators to extend DMARC's use to c-c mail broke the From: field
   semantic for third-party operations.
 * DMARC semantics really requires knowledge of an operator, not an
   author.  This is what makes it reasonable to ignore the From:
(left-hand-side) value.
 * In effect, DMARC has turned the From: field semantics into the
   Sender: field semantics.  (Note that DomainKeys was tied to Sender:,
   not From:.)  For RFC 733, we allowed the Sender: field to be omitted
   if the value was the same as for the From: field.

While it took 45 years to teach the lesson, it has become a stark 
example of the basic problem of creating a design that conflates semantics.


The Author: field is now available to have no 

Re: [mailop] The oligopoly has won.

[Dave Crocker via mailop]

On 9/14/2022 7:49 AM, Thomas Walter via mailop wrote:
If I have to check a spamfolder for false positives every day, I can 
just have them delivered to my inbox. The spamfolder does not have an 
advantage then.



Actually, it does, depending on how bad the false-positive and 
false-negative rates are.  If either is quite high, then yes, it 
probably is better to just have a single folder.


If the rates are tolerable, then the user can approach the two folder 
with significantly different attitude.  For one, you mostly expect valid 
stuff, but know there will be an occasional bit of spam.  For the other, 
you know there will mostly be spam with an occasional bit of goodness.  
The first is really a working folder.  The second is a scan-and-fix folder.


d/

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

Re: [mailop] The oligopoly has won.

[Dave Crocker via mailop]

-

On 9/12/2022 7:01 PM, Al Iverson via mailop wrote:

Because I disagree with the whole premise
that self hosting mail is impossible today



I believe 'impossible' is not the prevailing sentiment.  If it were, the 
various folk who run such services probably would be doing something else.


I believe the prevailing sentiment is that it is a challenging task, 
requiring significant expertise.


In that regard, you seem to be viewing yourself as representative of the 
larger population of possible email service providers.  In which case, 
you might want to review your understanding of sampling methodology.


d/

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

Re: [mailop] double-singing with 2 independant DKIM-signatures for same domain

[Dave Crocker via mailop]

On 8/26/2022 3:38 AM, Laura Atkins via mailop wrote:
Signing with 2 identical d= but different s= is unusual, but I don’t 
think it’s prohibited anywhere.


It's certainly not prohibited in the DKIM specification.


I also don’t think the RFC addresses anything about mail disposition 
in case of failures.


Simply put, a signature failure is supposed to be handled the same as no 
DKIM signature being present.


As for specifics...

6.3 . Interpret 
Results/Apply Local Policy It is beyond the scope of this specification to describe what actions

   an Identity Assessor can make,
...
   In general, modules that consume DKIM verification output SHOULD NOT
   determine message acceptability based solely on a lack of any
   signature or on an unverifiable signature; such rejection would cause
   severe interoperability problems.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] So, Sendgrid / Zoom, planning on actually doing anything about webinar spams?

[Dave Crocker via mailop]

On 7/23/2022 1:17 AM, Laura Atkins via mailop wrote:

On 23 Jul 2022, at 05:18, Bill Cole via mailop  wrote:


On 2022-07-22 at 12:45:18 UTC-0400 (Fri, 22 Jul 2022 12:45:18 -0400)
Luis E. Muñoz via mailop 
is rumored to have said:


On 22 Jul 2022, at 11:49, Laura Atkins via mailop wrote:

I question your assertion that "bounces for X sender doesn’t mean 
that it shouldn’t be mailed for Y sender". If recipient R has a 
history of blocking many senders, continuing to send from other 
senders is not worth it in the long run for the ESP. Just as 
receivers reject with errors such as "this account is receiving 
email at a rate that...", the ESP could respond to its client with 
"this receiver has a history of bounces / rejections / complaints 
that is incompatible with our policies...".


If only we had a framework for error codes in SMTP that carry useful 
semantics...


I agree, it would have been nice if the authors of 821 and 822 had 
considered this use case and provided us with semantics. 
Unfortunately, the semantics described in those RFCs (and their 
successors) only talk about what to do with the message that is 
rejected. There are no semantics or recommendations about what to do 
with future messages to the addresses that failed to accept the mail.



I recently had occasion to review the text for basic SMTP reply code and 
was intrigued to be reminded that it does not actually and definitively 
state that a given address does not exist.  Not a relevant concern, 
here, but another example of information not provided.


There are many reasons a particular address does not work and many of 
those reasons have nothing to do with the handling of other addresses at 
that site.


To the extent that a bulk sender wants to formulate a broader 
assessment, across addresses, that's their private heuristic, based on 
all manner of non-standardized information.  It's not something that can 
be built into an SMTP reply model.



d/

ps.  But yes, it is really remarkable just how little the authors of 821 
and 822 anticipated being needed, 40 years later...


pps. It is common to hear complaints about how little the originators of 
Internet tech considered security.  Comments almost never note that the 
hardware of the day could not support large-scale use of encryption...
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] ARC and not ARC, was Microsoft Announces Tenant Trusted ARC Seal

[Dave Crocker via mailop]

On 6/28/2022 3:32 AM, Alessandro Vesely via mailop wrote:
I agree that would've been better than ARC.  However, it'd still need 
to know which recipients are mailing list supporting DKIMv2 and 
operate accordingly. For example, on a reply-all the MSA should split 
the message and sign it regularly for regular recipients and 
conditionally for MLs. 



1. What do you mean by DKIMv2?

2. What features of v2 are relevant here and where are they in the spec?

3. How is an MSA to know, reliably and accurately, the difference 
between 'regular recipients' and MLs?


4. What do you mean by 'conditional' signing?


d/

___
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/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 to use the domain name.

The domain name is a bit of a red herring with this proposal. The actor 
(sender) is authorized by the receiver, period.


If the actor starts sending spam, they get docked. The definition of 
spam is by the receiver, which might use DKIM or simply say "new domain 
seen with this key", let's throttle these messages until we are sure.


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.




 > None of these specs and services say anything at all about 'reputation'.

They do. RFC6376  DKIM:

6.3.  Interpret Results/Apply Local Policy

    It is beyond the scope of this specification to describe what actions
    an Identity Assessor can make, but mail carrying a validated SDID
    presents an opportunity to an Identity Assessor that unauthenticated
    email does not.  Specifically, an authenticated email creates a
    predictable identifier by which other decisions can reliably be
    managed, such as trust and reputation.  Conversely, unauthenticated
    email lacks a reliable identifier that can be used to assign trust
    and reputation.  It is reasonable to treat unauthenticated email as
    lacking any trust and having no positive reputation.


Sorry my writing was lax:  By 'not saying anything', I meant not saying 
anything normative/actionable about the details of assessing reputation, 
per se, or that otherwise constitutes actionable specification.


The text you quoted pretty much reflects the statement I made here. 
(What a surprise.)





RFC7208  SPF:

8.3.  Pass

    A "pass" result means the client is authorized to inject mail with
    the given identity.  The domain can now, in the sense of reputation,
    be considered responsible for sending the message.  Further policy
    checks can now proceed with confidence in the legitimate use of the
    identity.  This is further discussed in Appendix G.1.


Again, this asserts authenticity to the use of the identifier, rather 
than a statement that the actor using the identifier is to be treated as 
having a good 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.

I disagree. There are many other words, like trust, that are used to 
describe reputation, e.g. RFC8617 
 ARC:


    ARC-enabled Internet Mail Handlers can process sets of ARC assertions
    to inform message disposition decisions, identify Internet Mail
    Handlers that might break existing authentication mechanisms, and
    convey original authentication assessments across trust boundaries.


If someone is tasked with buying good quality eggs, milk, and the like, 
they have a role in the creation of the pancakes (or waffles, or pasta, 
or..., but not really.


With respect to the assessment of email reputation, these specifications 
are similar to that distinction.



The words between the lines are you should (not SHOULD or SHALL) use ARC 
to manage reputation.


'manage reputation' is normally taken to refer to an assessment of 
reputation.  None of these specification specify that assessment 
process.  They provide some data that is hoped to be used as input to 
the assessment process, but say nothing about how.  No technical details 
or even guidance.





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

So DKIM keys can be used in the proposed scheme. That's fine by me.

What I would like is a protocol for bootstrapping trust (WoT), handling 
complaints, and querying reputation.


So would many folk.  And they have for roughly 30 years.

So far, efforts in that direction have not scaled well and none has 
attained any type of standards status.


It's possible that this is a difficult problem...


DKIM doesn't solve that problem. 


DKIM doesn't pretend to.



d/
___
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 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

[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

[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

[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

[Dave Crocker via mailop]

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.  It breaks when even simple MTA 
relaying is done through an MTA that is not pre-registered in the SPF 
record.  Such relaying has been an essential part of Internet mail since 
before there was an Internet.  SPF was designed after this entirely 
reasonable behavior was well-established.


The word 'justification' is probably awkward in this context, but the 
technical and operational details here are pretty simple.


DKIM was designed with an expectation that the basic message -- the part 
used to formulate the DKIM signature -- will not change.  That's a 
reasonable assumption for a single posting/delivery sequence.


Mailing lists create multiple such sequences before 'final' delivery. 
Mailing lists can and do do all sorts of things to messages that wind up 
breaking the DKIM signature. They always have.  Mailing lists, too, were 
well-established before there was an Internet and long before DKIM was 
developed.


These technologies were designed to work properly for only a subset of 
entirely reasonable email handling activity that has always existed.



SPF -> You should be aware of all the servers that can be involved in 
the message transaction 


No, actually you shouldn't.  It's a requirement that doesn't scale.


DKIM -> The message should only be signed after it is complete and 
leaving your controlled environment. Any modification to the message 
afterwards is tampering and should not happen.


See above.  DKIM is for a single posting/delivery sequence.  Mailing 
lists entail multiple.  Mailing lists operate at user-level, not the 
transport level. User-level software can and does do whatever it wants, 
prior to (re-) posting and always has.


d/
___
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/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 mailing 
list, rather than the author, removes the author's SPF from consideration.


Rather than 'breaking' SPF, conventional mailing list behavior simply 
removes the original SPF trigger.




Do note that SPF only cares about the envelope, it doesn't require the
RFC821 envelope to be aligned with the RFC822 headers inside DATA.
Passing DMARC is a different problem.


ack.

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

Re: [mailop] Microsoft Announces Tenant Trusted ARC Seal

[Dave Crocker via mailop]

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 FUD sayers about SPF and mailing lists, it has never been 
a problem with mailing lists, not using mailman nor its more common 
predecessor majordomo, and I've never noticed anything wrong with qmail 
users ezmlm.


This establishes the context of SPF and mailing lists.  Hence my question.

Also, the above text makes the incorrect assertion that this isn't a 
problem when a message passes through a mailing list.  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 point is what motivated ARC.)



If you have used some half baked concoction that doesn't conform to 
standards that's not an SPF failure, it's yours. I've enforced and 
published SPF since get go, I did extensive testing and never found ONE 
instance of a list problem.


The reference to standards, here, does not have any obvious linkage to 
well-known specifications.  Hence my question.



As for forwarding, SPF is only a problem if you dont follow standards 
and re-write.


Again, I've no idea what standards are being relied on here.  Nor do I 
believe there are any that are helpful to this issue.  Hence my question.



 Nearing two decades of SPF use (forget exactly its been so
long) never had a mailing problem sending or receiving with SPF and I've 
always published hard fail, rarely forward Email, and it seems our 
customers don't either.


This appears to rely on a single person's experience.  Never a good 
scientific method, except for that person's own use.


In any event, it is fully at odds with industry-wide reporting over 
those decades.  (It's also against the basic physics of the SPF design.)




d/
___
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/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 the 
author/originator get broken.


With ARC, besides a authenticated handling sequence, there is 
information about those original authentication tidbits that got broken, 
when the site providing the tidbits says how its own evaluation went.


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.


d/
___
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/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.


d/
___
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/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 your bottle down, sober up, and itll come 
back to you



Unfortunately, my note and its questions were serious.  Some of the folk 
on this list have seen what I post when I'm being facetious or otherwise 
attacking.  This wasn't that.


Sorry you feel inclined towards hostility rather than constructive 
engagement.


d/
___
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/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 
relevant standards. that would sustain SPF validation. However I don't 
have a guess at what standards you have in mind.


I also don't understand how SPF validates, when mail is simply relayed 
through an MTA that isn't pre-registered in the SPF DNS record. Are you 
thinking that it is natural and reasonable to pre-register all of the 
MTAs in a path, up to the receiving one that does SPF validation?


Please enlighten us.

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

Re: [mailop] FTC Report on Feasibility of Creating a 'Do Not Email' List

[Dave Crocker via mailop]

On 5/19/2022 7:57 AM, Luis E. Muñoz via mailop wrote:

In this case, not really.


oh.  gosh.  we've been wrong about this.  for 20 years.

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

Re: [mailop] FTC Report on Feasibility of Creating a 'Do Not Email' List

[Dave Crocker via mailop]

On 5/19/2022 6:58 AM, Luis E. Muñoz via mailop wrote:

On 19 May 2022, at 9:41, Dave Crocker via mailop wrote:


So, sure. We haven't been able to do individual-level blocking, so let's add a 
requirement for an additional bit of complexity. That will probably make this 
mechanism work a lot better...


Heh, appreciate the humor. It certainly won't make it work worse.


A reasonable view, I think, but it occurs to me that it could.  Taking a 
narrow, precise requirement -- even one we don't know how to satisfy -- 
can be made harder to satisfy by confusing the heck out, where an 
additional requirement creates a distraction.


This might move a "we don't know how to do it now, but might be able to 
figure it out" to a "we don't know how to do it now and almost certainly 
never will"...





My point if you will, is that requirements are more complex than what's stated. 
The reason we won't get them fulfilled—simple or complex—is because there is no 
incentive for the bad guys to follow the rules.


As noted earlier in the thread, there are some actors who are not 
criminally inclined.  Ignorant and/or aggressive, but willing to follow 
the rules, or at least mostly.  So, for example, they properly identify 
themselves.  And given a sufficiently forceful requirement, they will 
grudgingly conform.


The other view expressed in the thread was that such folk are not 
currently an interesting problem, but the criminally inclined are.  (I 
think aggressive legitimate companies /do/ warrant some effort, but it 
needs to be reasonably limited and efficient effort.  That's what we 
don't yet have.)




IIRC, there is (was?) a "National Do Not Call List" implemented in the US at 
the federal level. Telemarketers and other organizations are required by law to scrub 
their own lists against this federal registry. This has not made a dent in the amount of 
spam calls that I get on my various lines.


Telephone-level DNC is a different category of technological 
requirement.  Very different.


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

Re: [mailop] FTC Report on Feasibility of Creating a 'Do Not Email' List

[Dave Crocker via mailop]

On 5/19/2022 6:30 AM, Luis E. Muñoz via mailop wrote:

On 19 May 2022, at 8:42, Dave Crocker via mailop wrote:


[⋯] Domain level is not sufficient.

But is it though? A corporate providing email to its own users should certainly 
be able to express a policy that it does not want to allow any form of mailing 
list email to its users.


My point was meant as "not sufficient for individual do not mail 
indication".


But your response expresses a desire for an /additional/ feature, which 
is domain-level listing, along with individual level.


So, sure.  We haven't been able to do individual-level blocking, so 
let's add a requirement for an additional bit of complexity.  That will 
probably make this mechanism work a lot better...


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

Re: [mailop] FTC Report on Feasibility of Creating a 'Do Not Email' List

[Dave Crocker via mailop]

On 5/18/2022 11:01 AM, John R Levine wrote:

  but even though both are technically sound, nobody uses them outside of a
  few specialized communities which suggests that it's not going to happen.



btw, neither does cert management in a way that has been shown to scale 
across the open, heterogeneous Internet.


As such, calling either of them 'technically sound' is problematic.

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

Re: [mailop] FTC Report on Feasibility of Creating a 'Do Not Email' List

[Dave Crocker via mailop]

On 5/17/2022 8:44 PM, Luis E. Muñoz wrote:

I wonder if this one

( ) Public reluctance to accept weird new forms of money

should be complemented with a crypto version, to avoid triggering those that 
hate cryptos being compared with money?



Indeed.  In fact it seems clear to me that this is an example of a 
much-needed meta-template, for generating new checklists to cover each 
new hype-fest that appears.



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

Re: [mailop] FTC Report on Feasibility of Creating a 'Do Not Email' List

[Dave Crocker via mailop]

On 5/18/2022 11:01 AM, John R Levine wrote:
Hm, your copy of the message appears to have been cut off.  Here's the 
rest which you presumably missed:



I didn't.

Your opening echoed my language, in a form casting it as taking 
exception to it.


I was noting that your choice for interpreting my language was different 
than intended -- or, IMO, appropriate -- for the context.


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

Re: [mailop] FTC Report on Feasibility of Creating a 'Do Not Email' List

[Dave Crocker via mailop]

On 5/18/2022 10:32 AM, John Levine wrote:
> It appears that Dave Crocker via mailop  said:
...

Note that, in spite of DMARC, we still do not have per-user

>> authentication.

We have at least two flavors in PGP and S/MIME,


When something exists for 30 years and has market penetration that 
cannot even rise to the level of being called 'meager'. /WE/ -- it, the 
Internet community -- does not have that thing.


The issue is pragmatics, not existence proofs.

So while those two flavors exist and the code them often exists in many 
MUAs, neither of those flavors is of practical use to the general Internet.



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

Re: [mailop] FTC Report on Feasibility of Creating a 'Do Not Email' List

[Dave Crocker via mailop]

On 5/17/2022 4:40 PM, Anne Mitchell via mailop wrote:

"why we can't do that", culminating in "the Commission concludes that, under 
present conditions, a National Do Not Email Registry in any form would not have any beneficial 
impact on the spam problem. It is clear, based on spammers’ abilities to exploit the structure 
of the email system, that the development of a practical and effective means of authentication 
is a necessary tool to fight spam.


Note that, in spite of DMARC, we still do not have per-user authentication.

More importantly, IMO, mechanisms like this really only apply to 
legitimate businesses that might be a bit too aggressive.  While it is 
possible it would mitigate some of their aggression, the bigger problem, 
IMO, are the folk who operate in a criminal style, ignoring rules.


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

Re: [mailop] SMTP line wrapping breaking DKIM signatures when forwarding

[Dave Crocker via mailop]

On 4/29/2022 10:55 AM, Brandon Long wrote:
On Thu, Apr 28, 2022 at 9:39 PM Dave Crocker via mailop 
mailto:mailop@mailop.org>> wrote:

   Perhaps:

     An MTA that is relaying a message SHOULD NOT attempt to repair
     problems it detects with the message.

     If the MTA continues relaying the message, it MAY send an informal
     multipart/report note, back to the RCTP-TO address of the message,
     indicating the nature of the problem with the message.


RCPT-TO being the relay destination or the original destination?  I 
would think

you'd want to go to the MAIL-FROM as the creator of the message?


Oh boy... RCPT-TO being the brain fart that indeed was meant to be 
MAIL-FROM.  sigh.


Sorry for the mental gas-passing.  And thanks for catching that bit of 
silliness.




The details of the report would have to be provided, since this doesn't
fit within DSN details.


I think automated reports of these types of failures would be a bad 
idea, slightly
less bad if it was only done for authenticated senders, and if rate 
limited... and
sent to the postmaster and not the original sender, who is unlikely to 
have any

ability to change how the message was formatted.


Seems like any random automated report is problematic these days, so, 
yeah, I could imagine that specifying some constraints would make sense.


That said, plain ol' DSN failure messages seem to get sent to Mail-From 
pretty readily, still.  No?


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

Re: [mailop] SMTP line wrapping breaking DKIM signatures when forwarding

[Dave Crocker via mailop]

On 4/28/2022 1:52 PM, Dave Crocker via mailop wrote:
If writing a formal specification, yes, one needs careful language.  
This isn't that exercise.


This prompted me to consider language that might be suitable for an RFC. 
 Perhaps:


   An MTA that is relaying a message SHOULD NOT attempt to repair
   problems it detects with the message.

   If the MTA continues relaying the message, it MAY send an informal
   multipart/report note, back to the RCTP-TO address of the message,
   indicating the nature of the problem with the message.

The details of the report would have to be provided, since this doesn't 
fit within DSN details.


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

Re: [mailop] SMTP line wrapping breaking DKIM signatures when forwarding

[Dave Crocker via mailop]

On 4/28/2022 10:54 AM, John Levine via mailop wrote:

It appears that Dave Crocker via mailop  said:

So, rather than changing the message, do simply relaying of the
(unchanged) message, but also send a notification about the problem,
back to the SMTP Mail-From address.


Well, that's one approach.  The issue here is that you have two
things wrong and you can't fix one without breaking the other.



Actually, for the current discussion, there is only a single issue:

 Should an intermediate relay get fussy and modify the substance
 of a message?

The suggestion is to answer this with a limited 'no'.  No, don't change 
the message,  But yes, notify the originator/author that there is an issue.


That is, no, don't have the relay be an enforcing.  Yes, have it be an 
advisor.



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

Re: [mailop] SMTP line wrapping breaking DKIM signatures when forwarding

[Dave Crocker via mailop]

On 4/28/2022 1:25 PM, John R Levine via mailop wrote:

On Thu, 28 Apr 2022, Dave Crocker wrote:

Actually, for the current discussion, there is only a single issue:

    Should an intermediate relay get fussy and modify the substance
    of a message?


That is one way to look at it, but as I said in the message you just 
replied to, in this case not a particularly helpful one.


We can also have endless discussions about what "substance" means, e.g., 
just the body, body and some headers, body in ways that doesn't bother 
DKIM?



Sorry.  Thought the context here was quite specific:  A relaying MTA 
'fixed' problematic messsage content, thereby creating collateral damage.


In that context, don't 'modify the substance' was meant rather 
specifically.  If writing a formal specification, yes, one needs careful 
language.  This isn't that exercise.


Also sorry you don't find narrowing the focus of concern and simplifying 
the approach to handling the proffered topic helpful.


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

Re: [mailop] SMTP line wrapping breaking DKIM signatures when forwarding

[Dave Crocker via mailop]

On 4/27/2022 6:57 AM, Paul Vixie via mailop wrote:
i have a slight preference for "either relay it or bounce it but don't 
do a little of both". and  i must observe that in robotic e-mail, 
mail-from is often deliberately unreplyable. the only reliable error 
path is at the the end of DATA.



A delivery service notice does not have to be a bounce.  It can be a ... 
notice.


As for there being no Mail-From, well, yeah, in that case, don't send 
the notice.


Just to be clear, I am suggesting accepting and relaying the mail as an 
absolute.  The variable would be a notice back to the originating service.


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

Re: [mailop] SMTP line wrapping breaking DKIM signatures when forwarding

[Dave Crocker via mailop]

On 4/27/2022 6:30 AM, Michael Kliewe via mailop wrote:
Exactly. The best and easiest solution is to contact the sender and tell 
them to fix the problem, by either using "relaxed/relaxed" or by 
reducing the line length to <=998 bytes.



So, rather than changing the message, do simply relaying of the 
(unchanged) message, but also send a notification about the problem, 
back to the SMTP Mail-From address.


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

Re: [mailop] SMTP line wrapping breaking DKIM signatures when forwarding

[Dave Crocker via mailop]

On 4/26/2022 5:48 PM, Dan Mahoney via mailop wrote:

The pedantic* answer here might be to make postfix smart enough to not apply 
this logic*if*  there's a DKIM signature with simple/simple in the 
canonicalization.


It is always tempting to react to a specific anomaly by adding a 'fix' 
specific to it.  Unfortunately, over time, this tends to produce a rat's 
nest of idiosynchratic behaviors.


Where possible, it's better to take the case of the anomaly as a prod to 
consider whatever larger issue it is part of, and make any changes -- if 
needed -- from that larger perspective.


I think the thread did a reasonable job of this, by noting that relaying 
is the wrong place to enforce this kind of violation.


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

Re: [mailop] SMTP line wrapping breaking DKIM signatures when forwarding

[Dave Crocker via mailop]

On 4/26/2022 10:37 AM, Brandon Long via mailop wrote:

Transforming messages for relay is not likely to go well.



This seems an essential point.

It would be worth pressing for some discussion on it, and if possible 
develop as strong a rough consensus on as possible.


There is likely an easy position to take, based on formalities, but this 
being an operations-oriented list, one would hope that operational 
pragmatics would dominate...


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

Re: [mailop] SMTP line wrapping breaking DKIM signatures when forwarding

[Dave Crocker via mailop]

On 4/26/2022 2:49 PM, Robert L Mathews via mailop wrote:
I suppose the argument in favor of it is that some other places you 
might forward to will reject a message solely because it has line 
lengths longer than allowed, so you can't win either way.


This is an example of how it is useful to distinguish between an MSA 
(submission) from an MTA (relaying).  Having the former enforce 
niceties, at the source makes quite a bit of sense, notably because the 
MSA has a 'relationship' with the user and their MUA.  An MTA doesn't.


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

Re: [mailop] Fwd: RFC 9228 on Delivered-To Email Header Field

[Dave Crocker via mailop]

On 4/14/2022 5:22 PM, John R Levine wrote:

On Thu, 14 Apr 2022, Dave Crocker wrote:

Without knowing what mail software your provider is running, there is
no way to tell.


The benefit of an over-the-wire approach to specification writing is 
that all that matters is what goes... over the wire.  One does not 
need to know the 'intent' or 'thinking' or who the source is, or 
whatever about the source of the data that goess over the wire.  One 
merely needs to know what goes over the wire, and compare it to what 
is in the specification.


So, just so I don't misunderstand, you're saying that one can tell what 
a complex piece of software does by examining a single example of its 
output.  That's quite impressive.


John, I said nothing of the sort.  Which, of course, you know.

What is actually impressive is that what I recited about the 
over-the-wire model for interoperable protocol specification is the very 
mundane and long-standing foundation for Internet 101, but you somehow 
seem not to understand it.  Very large wow.




Section 4, second bullet

If a receiving system's delivery process applies mappings or
transformations from the address used by the MHS to a local value,
this new value SHOULD also be recorded into a separate Delivered-To:
field when transit and processing using that address successfully
complete. This ensures a detailed record of the sequence of handling
addresses used for the message.


covers that form of string.


It doesn't, we explained why last year, but since I doubt anyone else is 
interestied in this p*ing match, I'm really done now.


I asked a very simple question, for you to provide the technical 
specifics that are the basis for the conclusion you keep uttering.


Rather than participating in a constructive technical exchange, you have 
repeatedly insisted on aggressively relying on an appeal to your 
authority about this.  But that's not how open, collaborative technical 
work is done.


In effect, you've been done for quite a few months.

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

Re: [mailop] Fwd: RFC 9228 on Delivered-To Email Header Field

[Dave Crocker via mailop]

On 4/14/2022 2:09 PM, John Levine wrote:

It appears that Dave Crocker via mailop  said:

On 4/14/2022 1:27 PM, John Levine via mailop wrote:

Is anyone aware of any mail system that implements Delivered-To
the way this document describes,



Your query, to this list arrived at my inbox with these header fields:


Return-Path: 
Delivered-To: d...@dcrocker.net
Received: from mx.mailop.org (mx.mailop.org [91.132.147.157])
by gcp-europe-west4-b-smtpin5.hostinger.io (mx.hostinger.com) with 
ESMTPS id 4KfWJZ1H9Sz9v9X5


Without knowing what mail software your provider is running, there is
no way to tell.


The benefit of an over-the-wire approach to specification writing is 
that all that matters is what goes... over the wire.  One does not need 
to know the 'intent' or 'thinking' or who the source is, or whatever 
about the source of the data that goess over the wire.  One merely needs 
to know what goes over the wire, and compare it to what is in the 
specification.


So, the question remains:  In what way does the example I provided 
deviate from what is specified in the RFC?




As we explained at length last year when you were writing this draft,
Postfix and other mail systems put a loop breaking token in
Delivered-To. Sometimes it matches the envelope address, sometimes it
does not. The detail that it may look like a mailbox does not mean
that it is a mailbox.


As I explained in your similar challenge today on another list, that's 
covered in the specification:


Section 4, second bullet
> If a receiving system's delivery process applies mappings or
> transformations from the address used by the MHS to a local value,
> this new value SHOULD also be recorded into a separate Delivered-To:
> field when transit and processing using that address successfully
> complete. This ensures a detailed record of the sequence of handling
> addresses used for the message.

covers that form of string.

If you think better wording should have been used, perhaps you can point 
to the place in the discussion archive where you suggested it?  I made 
quite a few changes, in response to many suggestions.  I'm not recalling 
one, about this, from you.




The code in Postfix, qmail, and Courier and the spec are available to
anyone who cares to look at them and has been for well over a decade.


That's nice.  How is this point relevant here?



I'm not going to waste more time on this now.


Thanks.

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

Re: [mailop] Fwd: RFC 9228 on Delivered-To Email Header Field

[Dave Crocker via mailop]

On 4/14/2022 1:27 PM, John Levine via mailop wrote:

Is anyone aware of any mail system that implements Delivered-To
the way this document describes, 


Your query, to this list arrived at my inbox with these header fields:


Return-Path: 
Delivered-To: d...@dcrocker.net
Received: from mx.mailop.org (mx.mailop.org [91.132.147.157])
by gcp-europe-west4-b-smtpin5.hostinger.io (mx.hostinger.com) with 
ESMTPS id 4KfWJZ1H9Sz9v9X5
for ; Thu, 14 Apr 2022 20:29:02 + (UTC)

...> Date: 14 Apr 2022 16:27:53 -0400

Message-Id: <20220414202755.aee5f3dac...@ary.qy>
To: mailop@mailop.org
In-Reply-To: 
Organization: Taughannock Networks

...

List-Id: For mail operators 
List-Unsubscribe: ,
 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
 
From: John Levine via mailop 
Reply-To: John Levine 



if that does not conform to the RFC's specification, please explain how.



rather than for loop breaking
with a token that looks like a mailbox but isn't?


Since there has been no claim or expectation that the field already has 
deployed use beyond loop-detection and, in fact, the RFC explicit states 
that that larger role is one of the reasons it was issued as 
Experimental, your query is a bit odd.




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

Re: [mailop] Fwd: RFC 9228 on Delivered-To Email Header Field

[Dave Crocker via mailop]

On 4/14/2022 8:19 AM, Michael Peddemors via mailop wrote:
One thing that isn't addressed in that Dave, is cases where the 
Delivered To address exists, and the message is routed back out the 
internet,.  Still seeing cases in the wild where the Delivered To is 
added, but it isn't really the transfer of responsibility, but rather a 
routing of email to another system that will be doing that.


Delivered-To has existed for some (very long) time, specifically to aid 
in detecting loops, as the RFC notes.  Besides simply creating a formal 
spec for the field, the motivation for publishing it now is for enhanced 
use, beyond this.


So I'll assume that the 'routed back out the internet' means cases of 
forwarding, rather than relaying.  That is, sending the message on, with 
a new delivery (RCPT-TO) address.


Since that's what the field is intended to support, I'm not clear how 
this causes a concern (beyond the potential privacy concerns the 
document cites.)


Please clarify.


I think a comment on what to do with Delivered To headers that are added 
that really shouldn't exist.


OK.  Please provide detail.  It isn't obvious to me when the field 
should not be added, and what problems those cases cause.





This is also common to see in email replay spam etc.


how?


Also, a direct statement that Delivered TO is a type of trace header 
might be in order.


Section 4, 4th bullet.

The wording is intentionally a bit indirect, since a) the term has a 
long history, but little explicit definition.  The technical/actionable 
definition has typically been implied rather than explicit.  The 
emailcore wg has done some work on this, but it's for a document under 
development and I didn't want to rely on that work.





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

[mailop] Fwd: RFC 9228 on Delivered-To Email Header Field

[Dave Crocker via mailop]

Folks,

This was just issued. It will aid in evaluating handling history of a 
messsage, especially through aliasing and mailing list sequences.


d/

 Forwarded Message 
Subject: RFC 9228 on Delivered-To Email Header Field
Date: Wed, 13 Apr 2022 23:04:21 -0700 (PDT)
From: rfc-edi...@rfc-editor.org
To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org
CC: rfc-edi...@rfc-editor.org, drafts-update-...@iana.org

A new Request for Comments is now available in online RFC libraries.

RFC 9228

Title:  Delivered-To Email Header Field
Author: D. Crocker, Ed.
Status: Experimental
Stream: Independent
Date:   April 2022
Mailbox:dcroc...@bbiw.net
Pages:  10
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-crocker-email-deliveredto-10.txt

URL:https://www.rfc-editor.org/info/rfc9228

DOI:10.17487/RFC9228

The address to which email is delivered might be different than any
of the addresses shown in any of the content header fields that were
created by the email's author. For example, the address used by the
email transport service is provided separately, such as through
SMTP's "RCPT TO" command, and might not match any address in the To:
or cc: fields. In addition, before final delivery, handling can
entail a sequence of submission/delivery events, using a sequence of
different destination addresses that (eventually) lead to the
recipient. As well, a receiving system's delivery process can produce
local address transformations.

It can be helpful for a message to have a common way to record each
delivery in such a sequence, noting each address used in the sequence
to that recipient, such as for (1) analyzing the path a message has
taken, (2) loop detection, or (3) formulating the author's address in
a reply message.  This document defines a header field for this
information.

Email handling information discloses details about the email
infrastructure, as well as about a particular recipient; this can
raise privacy concerns.

A header field such as this is not automatically assured of
widespread use. Therefore, this document is being published as an
Experimental RFC, looking for constituency and for operational
utility. This document was produced through the Independent
Submission Stream and was not subject to the IETF's approval process.


EXPERIMENTAL: This memo defines an Experimental Protocol for the
Internet community.  It does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


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

Re: [mailop] Best mailbox provider for personal domain?

[Dave Crocker via mailop]

On 4/10/2022 5:26 PM, Philip Paeps via mailop wrote:
They support +-addressing and also offer something called "subdomain 
addressing":


Following Fastmail documentation, I just tried the subdomain scheme and 
it was rejected.


(The + scheme works.)

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

Re: [mailop] Best mailbox provider for personal domain?

[Dave Crocker via mailop]

I tested it, before posting my note saying they supported it.

d/

On 4/9/2022 9:26 AM, Tara Natanson via mailop wrote:

FASTMAIL -

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

Re: [mailop] Best mailbox provider for personal domain?

[Dave Crocker via mailop]

On 4/8/2022 6:40 AM, Tara Natanson via mailop wrote:
Where would you recommend hosting your domain so that you can pop/imap, 
use "+" addressing, isn't spammer friendly,



Fastmail seems to support + addressing.

Hostinger does not.

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

Re: [mailop] [EXTERNAL] Comcast "Security Edge Report"

[Dave Crocker via mailop]

I hope it is obvious that this represents a structural problem, not just 
an odd occurrence.


I'm sure I'm not the only one who also has suffered this type of 
inability to get incorrect use of my address fixed because I wasn't a 
'member' of the sending organization.


d/

On 3/16/2022 7:40 AM, Brotman, Alex via mailop wrote:
Send me a note, I’ll see what I can do.  I don’t work on that side of 
things, but hopefully I can find someone who does.

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

Re: [mailop] Musings on Mail Service Operators

[Dave Crocker via mailop]

On 2/2/2022 7:31 PM, Scott Mutter via mailop wrote:
Why is it impossible to take a look at what Instant Messaging protocols, 
SMTP, SMS do that make them successful and then blend those together 
into a new "email-like" system?


Because replacing widespread systems is vastly harder than one would intuit.

Staying with email as the focus, there was early desire to expand from 
simple text to support multimedia.  And there were multiple efforts, 
from the latter 1970s onward.


What succeeded was not replacing existing email but rather adding to it, 
with an optional layer -- MIME.



I'm not going to pretend to know what the ultimate solution might be.  
One of the major issues with email is the address spoofing that goes 
on. 


It is popular to think that this can be solved, but the reality has so 
far demonstrated that what cannot be solved in the real (wet) world 
cannot be solved on the Internet.  And spoofing, or the like, is part of 
that wet world, as well as the digital one.


The schemes people propose to 'fix' spoofing wind up working less well 
than hoped, such as by not scaling adequately, or by having collateral 
downsides.



     Would more 
need to be done to lock this down?  Absolutely.  But it's at least A 


Locking down tightly has downsides, as well as benefits.



Email was first invented in 1971 - that's over 50 years ago.  We've 


This being a list for technicians, forgive me for noting that Ray 
Tomlinson did NOT invent email in 1971.


Email dates back at least to the mid-1960s.  Tom van Vleck is the most 
likely candidate for bragging rights.


What Ray did was to creat /networked/ email.  And, of course, choose the 
at-sign as the mailbox@host syntax.




   Why not invent a new, more modern email alternative?  


One of the wonders of the Internet is that you are free to go do that. 
Create it.  Deploy it.  Develop support for it.  If you can.



Something that takes a lot of what we've learned from email usage over 
the years, what we've seen in instant messaging, SMS, and other computer 
communication protocols and builds on that from the ground up?  Wouldn't 
that be better than constantly adding band-aids to email/SMTP to fix 
problems that pop up?


Possibly, but also apparently not.  It is spectacularly difficult, risky 
and expensive to create a new, distributed infrastructure.  By contrast, 
it is only modestly difficult to add to an existing infrastructure (if 
one is very careful.)


MIME managed to turn text email into multimedia without modifying the 
global email infrastructure at all.  Only the author and the recipients 
had to adopt it.  This is astonishingly cheaper than if they/we had had 
to create an entire, global infrastructure for multimedia mail.


There will come a point at which there is a strong desire to add a 
feature that we can't figure out how to add to the existing email 
service.  But over those 50 years, we haven't hit that limit yet, in 
spite of so many changes needed.



And don't be afraid to say no when it comes to adding every little 
feature into this protocol.  I'm not a huge fan of mailing lists or 
distributed mailings (forums accomplish the same thing with less of the 
hassle of email deliverability concerns). 


Centralized platforms are much easier to develop and run than 
distributed ones, of course.  But they also are a pain, moving 
operational hassles to users, when one has to flit from one to the next, 
checking for new postings.  So, again:  tradeoffs.




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

Re: [mailop] Gmail does not validate DKIM for forwarded messages?

[Dave Crocker via mailop]

On 1/31/2022 7:43 AM, Al Iverson via mailop wrote:
In this scenario, my mailing list manager strips the original DKIM 
signature and applies its own, as I am now the party responsible for the 
message. (I also rewrite the from address.) This has worked fine for me, 
but not everyone is a fan of this methodology.



You're dealing with two different issues.

One is a broken DKIM signature, because mailing list processing almost 
always messes with the content.  (And that's always been ok, as I think 
it should be.  Adding a new signature of citing the list's domain makes 
complete sense, for exactly the reason you state.


The modified From: is because of a problem created be extended use of 
DMARC.  What is not generally noted is that, in effect, this is a means 
of defeating DMARC.


However, the From: modification also messes with the recipient's MUA 
handling of mail from the same person, where the mail that goes through 
a list with the From: modified isn't recognized as from the same author 
as sends mail directly to the recipient.


An attempt to work around the downside of the list's workaround is the 
Author: field that was recently specified:


 Email Author Header Field
 https://www.rfc-editor.org/rfc/rfc9057

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

Re: [mailop] 2 questions about BCC and mailing lists

[Dave Crocker via mailop]

On 1/31/2022 9:43 AM, Geoff Mulligan via mailop wrote:
1. If a recipient on an email message is both in the To: or Cc: and on 
the mailing list, should the listserver send the message to the recipient:

  a) By default
  b) Not by default (but configurable)
  c) Never


by default.  redundancy is safer than failed delivery and the mailing 
cannot know enough to know what other components are doing or what the 
users actually want.


The only time pruning is reasonable is when the entity doing the pruning 
has complete knowing.  Typically, that is only at the time of 
submission, so that multiple occurrences of the /same/ recipient address 
gets turned into a single SMTP RCTP-To.


Pruning at receive time might make sense, but it carries some dangers. 
Pruning anywhere along the path strikes me as gross dereliction of duty.



2. If a mailing list is in the BCC: should a message be delivered to the 
list:

  a) Yes - always
  b) No - never
  c) Configurable
  d) Convert it to a CC:


The question presumes that the handling system can know it is a mailing 
list.  It can't.


And by the way, if an author puts a mailing list into a BCC, of course 
they want the message delivered to the list.  What is the basis for 
pretending to know better and override that decision?


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

Re: [mailop] Walled gardens

[Dave Crocker via mailop]

On 12/29/2021 4:40 AM, yuv via mailop wrote:

Unfortunately, e-mail walled gardens are a Well Known Bad Idea.

RFCs-based e-mail is a walled garden.  We lawyers call this the Rule of
Law.



That's very creative.  Not what is normally meant, and not even slightly 
useful.  But very creative.


Well, actually it does have one use.  It makes clear that further 
discussion is not going to be productive.


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

Re: [mailop] Ethics Complaint to Princeton (was: Bizarre GDPR/CCPA scam spam from Princeton researchers)

[Dave Crocker via mailop]

FYI

sigh.

d/



 Forwarded Message 
Subject:Re: [IP] Bizarre GDPR/CCPA scam spam from Princeton researchers
Date:   Tue, 21 Dec 2021 14:10:45 -0800
From:   Edward Hasbrouck 
Organization:   The Practical Nomad
To: i...@ip.topicbox.com



I got through today to the grad student involved in the scam spam 
project, Ross Texeira -- his phone number is on his Web site.


He was unapologetic and unhelpful. He said he was "unable" (meaning 
unwilling) to send a copy of the Princeton IRB application or approval, 
or the algorithm used to identify e-mail addresses "designated for CCPA 
or GDPR subject access request". He said the criteria included the 
appearance of the words "privacy", "GDPR", or "CCPA" on Web pages. So 
any e-mail address on a site that talks about these issues might be 
swept in.


Most interestingly, he said that they sent e-mail to between 200K and 
300K e-mail addresses, scraped from Web sites on a list of the "top" 1M.


That's small compared to the numbers of messages sent by many for-profit 
spammers, but still a huge commandeering of other people's time, 
especially given the baseless claim that a response was "required".


Do the math: If each recipient spent an hour on deciding whether and how 
to respond, and then doing so, at minimum wage of $15/hour, that's $3M.


Since they apparently expect other US-based nonprofit entities not 
subject to the GDPR or CCPA to have procedures in place for responding 
to subject access requests, I asked if they have such procedures 
themselves, or how I can find out what info about me they have scraped 
up. He wouldn't answer.


He said to expect another update on their Web site later today, and that 
all other questions would be answered "when we publish our case study". 
He's still hoping to get publication credit for a paper out of this!


He referred all other questions to the principal investigator, Jonathan 
Mayer, who has not responded to my e-mail and voicemail messages.


Peace,

Edward Hasbrouck


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

Re: [mailop] Ethics Complaint to Princeton (was: Privacy research spam apparently from a grad student at Princeton)

[Dave Crocker via mailop]

On 12/17/2021 6:40 AM, yuv via mailop wrote:

* On the big issue, the ENROLLMENT OF HUMAN SUBJECTS WITHOUT CONSENT
into the study, I have been told that "[t]he IRB determined that our
study does not constitute human subjects research."



I haven't gone through an IRB process.  So I've no idea what the 
dynamics, practical criteria, or typical outcomes are from them.


But this particular decision seems bizarre.  Beyond concern for this IRB 
repeating the error, it occurs to be that it could be replicated by 
other IRBs.


That makes me wonder about the possible benefit of 
independently-developed guidance that might be circulated among them. 
Possibly from a respected anti-abuse organization?



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

Re: [mailop] Idea for new internet standard: DKIM-QR

[Dave Crocker via mailop]

On 12/11/2021 3:33 PM, Sebastian Nielsen via mailop wrote:

The idea here was that it would be easier kind of, to create DKIM validation 
method, that only the sender and the sender's server need to be take part it, 
and then any user can validate the email, regardless of lack of support in the 
client or receiving server.



The premise appears to be that recipients are relevant to the effort at 
validating email.


They aren't.

Userful validation at scale is done by the incoming -- and sometimes 
outgoing -- filtering engine run by the email platform.



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

Re: [mailop] Google DNS Quad 8 Outage tonight (Grant Taylor)

[Dave Crocker via mailop]

On 11/23/2021 6:11 PM, John Levine via mailop wrote:

On 11/22/21 12:25 PM, Michael Peddemors via mailop wrote:

...

I'm going to lump "Site Finder" in the malicious category.  No NXDOMAIN
for you!  Have this add instead!!!

That was ten years ago, you know.



2003.  Closer to 20.

https://en.wikipedia.org/wiki/Site_Finder



Surely we have more recent stuff to be upset about.


Sure, but with so much capacity and inclination for upsetitude, why 
limit ourselves?



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

Re: [mailop] WhatCounts/Costco silliness

[Dave Crocker via mailop]

On 10/26/2021 9:56 AM, John Levine via mailop wrote:

On the one hand, historically the opt-out has been in the body of the message, 
but a whole
lot of mail programs now recognize List-Unsubscribe and give you an option in 
the frame of
the message which is easier to recognize


1. But others do not

2. And many/most/all hide fields they don't recognize

3. Which means that while the information is in the message, it isn't 
normally visible to some/many recipients.


Which would seem to violate the intent of the requirement.

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

Re: [mailop] IMAP and SMTP in the same or separated IPs?

[Dave Crocker via mailop]

On 10/18/2021 12:35 PM, Brandon Long wrote:
Anyways, I stand by that there is unlikely to be overlap between people 
blocking your

smtp server and your customers accessing your imap server...


yup.  and that's why I asked for a detailed explanation from anyone 
claiming a linkage.  Haven't seen one appear, so far.


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

Re: [mailop] IMAP and SMTP in the same or separated IPs?

[Dave Crocker via mailop]

On 10/18/2021 10:56 AM, Brandon Long wrote:



On Sat, Oct 16, 2021 at 2:35 PM Dave Crocker via mailop 
mailto:mailop@mailop.org>> wrote:




On 10/15/2021 5:40 PM, Grant Taylor via mailop wrote:
 > The motivation for spreading service IPs across different /24
prefixes
 > is so that if

The issue here is not the generic one of using multiple IPs.  It is
about using them to separate IMAP from SMTP.  That's an entirely
different matter.

To the extent that anyone claims that there is a reptuation-related
reason for this kind of separate, for this kind of service distinction,
they need to provide substantial detail that makes the validity of the
reason crystal clear.


I have not seen it specifically for IMAP and SMTP, but I have seen it 
for SMTP and HTTP.


Indeed. Both of those get into the reputation game (and do need to.)

IMAP is used with an internal login.  Separate reputation analysis, in 
the style of an abuse filtering engine, doesn't make sense to me.



Specifically, I've seen people block http(s) access to an A record based 
on a hostname pointed at it
being advertised in spam or if the smtp server and web server are 
shared, ie they don't block by port

instead, they use a broad block in both directions.


Sure, if a bad actor -- who doesn't have to log in - connects to a 
service, it makes sense to accumulate whatever reputation of them you 
can, across services.


But as soon as the system connecting has to privately register with you, 
for on-going access, I'd expect that to involve a /very/ different 
assessment engine, since there is more and persistent knowledge about 
them.


I suppose that knowing the connect from an address that is problematic 
might be interesting, but, well... sigh.





I wouldn't be overly worried about it for IMAP, given that your IMAP 
customers are likely quite different than
who they are mailing, so it seems the likely overlap of those blocks is 
going to be small.


Exactly.

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

Re: [mailop] IMAP and SMTP in the same or separated IPs?

[Dave Crocker via mailop]

On 10/15/2021 5:40 PM, Grant Taylor via mailop wrote:
The motivation for spreading service IPs across different /24 prefixes 
is so that if


The issue here is not the generic one of using multiple IPs.  It is 
about using them to separate IMAP from SMTP.  That's an entirely 
different matter.


To the extent that anyone claims that there is a reptuation-related 
reason for this kind of separate, for this kind of service distinction, 
they need to provide substantial detail that makes the validity of the 
reason crystal clear.


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

Re: [mailop] IMAP and SMTP in the same or separated IPs?

[Dave Crocker via mailop]

On 10/15/2021 6:44 PM, Grant Taylor via mailop wrote:
I can see a hypothetical scenario where a client is running a firewall 
that is filtering connections based on IP reputation.  So if an SMTP 
server is erroneously listed, said firewall might block the IP, thereby 
blocking the client's access to the IMAP server if it was on the same IP 
as the SMTP server.


while reputation is a component of the example, I think the actual 
argument is more generic:  If something bad happens to one service, 
having the other on a separate IP address will tend to isolate it from 
that bad effects.


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

Re: [mailop] IMAP and SMTP in the same or separated IPs?

[Dave Crocker via mailop]

On 10/15/2021 5:40 PM, Grant Taylor via mailop wrote:

On 10/15/21 5:37 PM, Dave Crocker via mailop wrote:
Yes, but... That's the point that is intuitively reasonable which 
doesn't make real sense to me, after thinking about it.


What doesn't make real sense to you?  The relation of reputation and 
spreading services across multiple IPs?



I'm not seeing how 'reputation' interacts for these two functions.



Let's try I again.  I said "for these two functions".

The original query, as noted in the Subject line, is for IMAP and SMTP.

How does reputation for SMTP activity interact with IMAP activity?

And what does reputation mean, relative to IMAP activity?

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

Re: [mailop] IMAP and SMTP in the same or separated IPs?

[Dave Crocker via mailop]

On 10/15/2021 2:17 PM, Grant Taylor via mailop wrote:
The question of IP-based reputation intuitively seems like it might 
make a difference, but I'm not seeing a practical sequence in which is 
actually does.


I'd think that you would need the IPs to be in different /24 prefixes to 
avoid any network based reputation problems.  Separate IPs in the same 
/24 prefix might deal with individual IP listings.



Yes, but... That's the point that is intuitively reasonable which 
doesn't make real sense to me, after thinking about it.


I'm not seeing how 'reputation' interacts for these two functions.


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

Re: [mailop] IMAP and SMTP in the same or separated IPs?

[Dave Crocker via mailop]

On 10/15/2021 11:10 AM, Grant Taylor via mailop wrote:
That way when you want to migrate something, you can migrate it 
independently of everything else and you aren't forced to migrate 
everything at one time.


This has always been the preeminent reason for separate naming that I've 
understood.


However the question was about same/separate IPs.

The question of IP-based reputation intuitively seems like it might make 
a difference, but I'm not seeing a practical sequence in which is 
actually does.


Other than performance, which means independent platforms, where 
different IPs would typically happen as a side-effect, rather than an 
intent.


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

Re: [mailop] How important is an ipv6 ptr record?

[Dave Crocker via mailop]

On 2/10/2021 5:24 AM, Ken O'Driscoll via mailop wrote:

IPv6 space is considered low quality from an email perspective, so the answer 
is yes, receivers are likely to care about missing rDNS.


I'm interested in understanding the 'low quality' basis.

I don't have direct, hands-on for this.  So my sense of the issue is 
based on comments from those who do, within an anti-abuse group.


My impression from that has been a motivation to demand much stricter 
behaviors -- not from demonstrated difference in traffic for v6, 
compared with v4, but from a concern that IP-level analysis can't be 
effective.


The much larger address space makes it too easy for a bad actor to jump 
around and, therefore, not develop a bad reputation associated with the 
address.  So non-history features are made more strict.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] RFCs on quoted pairs in From:?

[Dave Crocker via mailop]

On 1/29/2021 8:11 AM, Jay R. Ashworth via mailop wrote:

The job of standards like RFCs is to *define the interface between syntax
and semantics*, as I see it: they tell you what the data *means*.  That's
information that's in the domain of end applications as well, as I see it:
the MUA should care what the RFC thinks about the semantics of that data,
since everyone else is already singing off that page of the hymnal.

No standard forces a telephone to use NPAs rather than ZIP codes at the
front of a phone number, I don't think, but you won't interface with the
network (for which Bellcore's "Notes (heh) on the Networks" is that
standard)...



Just to make clear that I'm not fond of appeals to authority, including 
my own, I'll note that folks with every bit as much experience as I have 
often -- maybe even usually -- disagree with my assessments.  But often 
isn't always...


A standard defines the sandbox it plays in.  It's essential that the 
four walls of that sandbox (to mix metaphors) be quite clear.  The 
alternative is a mess.  Every time.


That's why I had the prefatory comment, in my previous note, about 
activity that is outside the email protocol specs.


The phrase *define the interface between syntax
> and semantics* isn't clear to me, since I think of them as an 
integrated set, except at a very, very low level.


But I think the issue, here, is not about the syntax or semantics 
/within/ the email specifications, but outside of them.


As I said, the specialized adaptation of display-name that has happened 
in reaction to DMARC has no formal documentation or approval. 
Everything about it is ad hoc.  To the formal email specification, 
display-name is an uninterpreted literal strong.  Nothing more.


When an MUA gets clever, while formulating a reply message, it might be 
clever good and it might be clever wrong, but its cleverness is fully 
and completely outside of any existing standard.


And...

Although I showed some restraint in my earlier note, I will now point to 
two specifications I put together, seeking a less hacky way of dealing 
with this DMARC-generated issue:


Author Header Field
https://datatracker.ietf.org/doc/draft-crocker-dmarc-author/

https://datatracker.ietf.org/doc/draft-crocker-dmarc-sender/
DMARC Use of the RFC5322.Sender Header Field


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] RFCs on quoted pairs in From:?

[Dave Crocker via mailop]

On 1/28/2021 7:22 AM, Jaroslaw Rafa via mailop wrote:

Dnia 28.01.2021 o godz. 07:11:54 Dave Crocker via mailop pisze:

It's possible that a recipient's MUA could 'know' about this
convention and would be able to deconstruct it, possibly with the
goal of discerning the email address of the actual author.  In an
attempt to regain some of the filtering and organizing benefits that
can accrue from having a consistent email address identifier.

Even if that's the case, then if MUA sees two things that look like email
address in the From: field, it should ask the user to which one should the
reply be sent, and not arbitrarily picking one of them (and the wrong one,
to be worse).



That's a human factors (usability) issue, not an email standards issue.

The basis for making and justifying appropriate, specific usability 
decisions is not nearly as straightforward as any of us might wish, but 
such is the nature of human cognition and behavior, and social context.


d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] RFCs on quoted pairs in From:?

[Dave Crocker via mailop]

On 1/27/2021 10:29 PM, Jay R. Ashworth via mailop wrote:

So you agree with him that an angle-bracketed address*inside quotes*  should
be ignored by an MUA -- at least if there's a valid address not inside quotes
in the same header?

Should the MUA go inside the quotes in the header to find one if there isn't
one that's quoted?  Or should it error out as "no address to reply to"?
I would think it should error; the 'protection' of the quoting shouldn't
be conditional.

Sounds like Thomas thinks Tbird has a bug in its header parsing code, and I
agree with him -- and, I think, you.



Well... maybe a bug.  Possibly not.

The standards pertain to interaction between standardized functional 
(networking) components.  At the very beginning and the very end of the 
chain of standardized components are components that are outside of the 
standards.  End points that actually /use/ the data, on behalf of an 
author or recipient.


Since this is outside the standards, there are no official rules for 
what is allowed or disallowed.


Within the RFC 5322 standard, a quoted display-name string is a bag of 
uninterpreted bytes, except as noted in the ABNF I cited before. 
Anything that goes into that string and 'interprets' it is outside the 
standard.


So the first question is whether the behavior in question is part of 
some standards-based activity with the string, or is it beyond/after that?


For example...

Because of DMARC, mailing lists often modify the From: field so the 
address part (addre-spec) refers to the list platform, itself, rather 
than the original author -- that is, disable DMARC processing for the 
message -- and modify the display-name string by adding the address that 
was in angle-addr part, possibly also adding some sort of 'via' text to 
state that it went through a mailing list.


There are no standards for this modification, but there are conventions. 
(In this case, calling it a de facto standard seems excessive, since it 
isn't documented or reliably deployed.)


It's possible that a recipient's MUA could 'know' about this convention 
and would be able to deconstruct it, possibly with the goal of 
discerning the email address of the actual author.  In an attempt to 
regain some of the filtering and organizing benefits that can accrue 
from having a consistent email address identifier.


But note the tentative phrasing I used.  I'm just guessing.

It might do this well or poorly, but it's still entirely outside of the 
formal standards.


So it might be a bug, but not an RFC violation.  Or it might be really 
clever and useful, in spite of surprising you.  But I did say 'might'.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] RFCs on quoted pairs in From:?

[Dave Crocker via mailop]

On 1/27/2021 4:40 AM, Thomas Walter via mailop wrote:

My understanding is that a quoted pair can contain characters that
otherwise would be treated differently. Characters like spaces, but also
angle brackets and such.

So in the following header, the address should be the last part in angle
brackets (""), but the first part should be the
"name" part, including the angle-brackets and email - "Some Person
"?



That sounds right.

Relevant ABNF from RFC 5322, where the comments for qtext are probably 
the most helpful:



qtext   =   %d33 / ; Printable US-ASCII
   %d35-91 /  ;  characters not including
   %d93-126 / ;  "\" or the quote character
   obs-qtext

   qcontent=   qtext / quoted-pair

   quoted-string   =   [CFWS]
   DQUOTE *([FWS] qcontent) [FWS] DQUOTE
   [CFWS]



d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Effeciveness (or not) of SPF

[Dave Crocker via mailop]

On 12/6/2020 7:32 AM, Mary via mailop wrote:

5. SPF provides a serious block to phishing attacks.


Given the nature of phishing and, especially, its reliance on the 
message body, rather than on header fields in the message -- nevermind 
the SMTP return address -- it would be interesting to hear the basis for 
you assessment.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [mailop] [E] Re: BIMI pilot @ Google

[Dave Crocker via mailop]

On 7/27/2020 9:49 AM, Al Iverson via mailop wrote:

Is it possible that a complaint that a postmaster's note about what
he thinks his users like can't be trusted because it lacks a 
scientifically rigorous study might possibly be off topic for an 
operational considerations list? Asking for a friend.



Well, ummm...  It wouldn't surprise me to find that the entire thread 
was off topic, given that the opening note contained:


On 7/22/2020 5:49 AM, Sidsel Jensen via mailop wrote:
I read today at 
https://cloud.google.com/blog/products/g-suite/gsuite-security-updates-for-gmail-meet-chat-and-admin - 
that Google/Gmail is starting a BIMI pilot.
I hope Google will share the results of the pilot - perhaps at the next 
M3AAWG?



Which, arguably, isn't all that different in kind from the query I made 
today.


The meta-challenge is that while this is an ops list, comments that 
might be taken as 'marketing' of a new capability pretty much beg for 
queries about the basis for its benefits.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [E] Re: BIMI pilot @ Google

[Dave Crocker via mailop]

On 7/27/2020 7:59 AM, Marcel Becker via mailop wrote:
On Mon, Jul 27, 2020 at 3:55 AM Dave Crocker > wrote:




My quote above did not claim that. I explained why we participate

in BIMI.

Perhaps you have data to support a claim of differential user
behavior?


I am not sure you read what I wrote.



Ahh, I see my query was too mild and too superficial.  I am guessing 
that you think your speaking from authority:


On 7/22/2020 3:45 PM, Marcel Becker via mailop wrote:

However the majority of our users prefer meaningful avatars and
brand logos in their email experience as it helps them identify email
senders and it helps with them with triaging.


makes my query redundant, but of course my query wasn't for your 
reassuring conclusion but for the sharing of research data that allows 
others to evaluate the methodology and the results on their own.


d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [E] Re: BIMI pilot @ Google

[Dave Crocker via mailop]

On 7/26/2020 7:31 PM, Marcel Becker via mailop wrote:
On Sat, Jul 25, 2020 at 11:12 AM Dave Crocker via mailop 
mailto:mailop@mailop.org>> wrote:


On 7/22/2020 3:45 PM, Marcel Becker via mailop wrote:
 > However the majority of our users prefer meaningful avatars and
brand
 > logos in their email experience as it helps them identify email
senders
 > and it helps with them with triaging.

Claims that presenting logos to users aids in anti-phishing efforts are
counter-factual. 


My quote above did not claim that. I explained why we participate in BIMI.



Perhaps you have data to support a claim of differential user behavior?


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Dave Crocker via mailop]

On 7/25/2020 2:41 PM, Robert L Mathews via mailop wrote:

On 7/25/20 1:52 AM, Christian de Larrinaga via mailop wrote:


My question is is it useful?

Yes, absolutely. If it's a security-sensitive message, like one from my
bank, it's useful for my mail client to show that it was really sent by
(DKIM signed by) them to increase my trust in it. My bank does not sign
messages in any other way, so DKIM is all I can check in terms of
digital signatures.



You appear to be using yourself as the sole source for assessing 
efficacy.  That's not how broad-based efficacy is established. Anecdotal 
data like this is mostly misleading.


You need to be able to demonstrate that there is efficacy for the 
general user population.


d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] BIMI pilot @ Google

[Dave Crocker via mailop]

On 7/25/2020 2:32 PM, Suresh Ramasubramanian via mailop wrote:
Oh, all I’m saying is that presenting the logo without a proper check or 
after being fooled into a proper check would be a problem.  And there’d 
be some creative ways (css? logo included at random other places in the 
friendly from? etc) spammers would look at mimicking such a logo



spammers explore any avenue they can find that looks at all promising. 
but just because they do something does not mean it is effective.


So, yes, I fully expect them to spoof -- where that means what the word 
'spoof' actually means -- logos.  Whether it it will have an effect on 
end-user deception is a different matter.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop