Subject: [Emailcore] Ticket #30: Erratum 4055: Description of SPF and DKIM is wrong

From: Todd Herr <[email-masked]>
Date: Fri, 9 Jul 2021 15:42:56 -0400

Greetings.

I would like to start a discussion of ticket #30 -
https://trac.ietf.org/trac/emailcore/ticket/30

Section 3.6.2 in draft-ietf-emailcore-rfc5321bis contains the following
paragraph:

   This specification does not deal with the verification of return
   paths for use in delivery notifications.  Recent work, such as that
   on SPF [41] and DKIM [43] [44], has been done to provide ways to
   ascertain that an address is valid or belongs to the person who
   actually sent the message.
   [[5321bis Editor's Note: Proposed erratum (4055) suggests that DKIM
   and SPF have nothing to do with this and that everything after the
   first sentence should be dropped.  An alternative would be to tune
   the texts.  ???]]
   A server MAY attempt to verify the return path before using its
   address for delivery notifications, but methods of doing so are not
   defined here nor is any particular method recommended at this time.

The strawman proposal here is to rewrite the paragraph as follows:

   This specification does not deal with the verification of return
   paths for use in delivery notifications.  A server MAY attempt to verify

   the return path before using its address for delivery
notifications, but methods
   of doing so are not defined here nor is any particular method recommended

   at this time.

Thoughts?

-- 

*Todd Herr* | Technical Director, Standards and Ecosystem
*e:* [email-masked]
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Michael Peddemors <[email-masked]>
Date: Fri, 9 Jul 2021 13:09:07 -0700

Should not verfication be done on the MAIL FROM itself, before the 
Return-Path header is added?

And also, where do you draw the line on discussing verification, and 
when does this cross over to spam and forgery detection, and not the 
core of email delivery, I would suggest that line be carefully 
considered before adding and recommendations, or permissions or 
suggestions to validation.

And of course, there is a whole bundle of considerations, eg validating 
bounce and other mechanisms like <>.  However, I do think that the very 
basic, eg if not authenticated, or permitted to relay AND a domain part 
is present, their SHOULD be a valid A or MX record for that domain, that 
allows for a theoretical bounce or a way to determine a mechanism to 
notify the administrator responsible for that domain.

However, there are many implementations that do not do those basics, eg 
the admin that is concerned that he might reject email, simply because 
their DNS or the sender domain DNS server are offline at the moment.

Probably should be very clear what to do when validating this 
information, eg they should only send a 4xx if it is a validation 
problem, but maybe a 5xx if they can confirm it is a malicious use?

Just thoughts to add to this thread.

On 2021-07-09 12:42 p.m., Todd Herr wrote:
> <https://trac.ietf.org/trac/emailcore/ticket/30>
> 
> This specification does not deal with the verification of return paths 
> for use in delivery notifications. A server MAY attempt to verify
> 
> the returnpath before using its address for delivery notifications, but 
> methods of doing so are not defined here nor is any particular 
> method recommended
> 
> at this time.
> 
> 
> Thoughts?
> 
> 
> -- 
> 
> *Todd Herr*| Technical Director, Standards and Ecosystem
> *e:[email-masked] <mailto:[email-masked]>
> *m:*703.220.4153
> 
> distribution of the information included in this transmission is 
> prohibited and may be unlawful. Please immediately notify the sender by 
> replying to this email and then delete it from your system.
> 
> 

-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 9 Jul 2021 13:16:17 -0700

> methods of doing so are not defined here nor is any particular 

Definitely better.  References to details that are outside the actual 
scope of the current specification create a forward reference that 
invites problems.

But I will suggest that the MAY is a pseudo-specification. It proffers 
normative language but has not technical substance.

Hence, perhaps:

This specification does not deal with the verification of a return path
for use in delivery notifications. Verification of the return path is 
outside the scope of this specification.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 13 Jul 2021 13:27:33 +0200

On Fri 09/Jul/2021 22:16:17 +0200 Dave Crocker wrote:
>> This specification does not deal with the verification of return paths for 
>> use in delivery notifications. A server MAY attempt to verify
>> method recommended at this time.
>>
>>
>> Thoughts?
> 
> Definitely better.  References to details that are outside the actual scope of 
> the current specification create a forward reference that invites problems.
> 

An implied normative point is that, should the verification fail, the server 
could even reject the transaction.

There are two passages where the draft alludes to SPF:
Section 3.6.2. (#30) this ticket about MAIL FROM, and
Section 4.1.4. (#47) about HELO/EHLO.

To increase parallelism between those sections, I'd drop the "for use in 
delivery notifications" phrase.  If verification is OT, its purpose and the 
possible reactions to its failure are also OT.  An attempt:

    This specification does not deal with the verification of return paths.
    A server MAY verify that the returnpath is valid or viable, but methods of
    doing so are not defined here nor is any particular method recommended at
    this time.

Should this paragraph also refer to Section 7.8 or 7.9?

jm2c
Ale
--