Subject: Re: consensus call on pra/mailfrom deployment and versioning/scope

From: Danny Angus <[email-masked]>
Date: Thu, 9 Sep 2004 16:25:30 +0100

All,

> Crypto-related standards (a field crippled with patents) often use the
> very same method to allow interesting (but potentially infringing)
> algorithms. See RFC 2246 for instance. You do not object against it
> because it mentions the patented IDEA?

To be honest from what I can see there doesn't really need to be a
specification for PRA at all as it merely formalises the correct
interpretation of RFC2822 compliant headers.

"This document describes an algorithm that allows one to determine who
   appears to have most recently caused an e-mail message to be
   delivered.  It does this by inspecting the headers in the message.
   [RFC2822]"

PRA could just as easily be replaced by a requirement to interpret headers
in accordance with RFC2822,

Marid core 4:
"Determining the Purported Responsible Address

   The purported responsible address (PRA) of a message MUST be
   determined using the algorithm described in [PRA].

   If the Sender ID check is being performed by an MTA as part of
   receiving an e-mail message, and the PRA algorithm cannot determine a
   PRA, then the message SHOULD be rejected with error "550 5.1.7
   Missing purported Responsible Address""

This could be redrafted as

"Determining the domain responsible for introduction of the message into
the messaging system MUST be in accordance with RFC2822."

and "ver-scope"  could be redefined to refer to a definition of the senders
domain written in refrence to rfc2822 alone.

It would then be the responsibility of the implementor to deal with their
own IPR issues, though what a can of worms would be opened if a patent
could be taken out on any algorythm implied but not explicitly stated by
any RFC.

It strikes me that crypto algorithms are the product of much commercial
effort and the ends of ineroperability are better served by incuding them
in an interoperability framework than omitting them. This case is different
in that a party to an interoperability standard seems to have indicated
that they intend to seek patents based upon work done by the group and
which will probably affect implementations but will not be granted or
revealed until after the standard has been published.

d.

(p.s. I'm an Apache James PMC member)

***************************************************************************
The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any  responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limi!
 ted.

This footnote also confirms that this email message has been swept for the presence of computer viruses.

**************************************************************************

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Sep 2004 14:55:35 +0200

On Thu, Sep 09, 2004 at 08:32:46AM +0800,
 AccuSpam <[email-masked]> wrote 
 a message of 19 lines which said:

> We will end up with a fragmented internet e-mail system separated
> into proprietary (pra) and free software (mailfrom). 

Some people like Paul Vixie believe that it is unavoidable because
there is no consensus on the "best" identity (scope) to check. Reading
MARID archives again and again, I believe they are right. Even without
the patent issue, there is no consensus on PRA (or on MAIL FROM). So,
"Unified SPF" is the only solution. Not perfect but reasonable.

May be in the future, the "proper" scope will be obvious and all the
others will become deprecated. But we are far from it.

---

From: AccuSpam <[email-masked]>
Date: Fri, 10 Sep 2004 21:38:00 +0800

>Note that I take no position on the usefulness of these scopes. I
>simply believe that, given the current state of the art about email
>identities, it is better to have choice.

So why declare algorithm scope?

I could support algorithm scopes, if all applicable scopes were in a single record.  2nd to the Nth records would be ignored.

Thus the intent would be for a single record to interopt with all current and future scopes (updated by version number), and the sender can hint the limitation of intended scopes.  This would be more in touch with reality IMO, and also appease the desire to give sender some input into algorithm scope, while also preventing fragmentation and proprietary directions (wars) on DNS records.

- Shelby Moore