Subject: Changes for protocol-01

From: Mark Lentczner <[email-masked]>
Date: Fri, 13 Aug 2004 15:36:07 -0700

Friends -

draft-ietf-marid-protocol-01 has been submitted.  In addition to the 
changes I mentioned previously in this list, it includes:

   Major Changes
   * Language for new DNS RR type from DNS-EXT folks:  Compliance now
     requires using new RR type, and EDNS0 compliant software.
   * Added back %{p} macro that was removed in last rev - some people 
use it
   * Changed the version to "spf2.0/pra" and added future extension 
support

   Descriptive Changes
   * Clarified interpretation of domain-spec after macro expansion
   * Clarified that new mechanisms can only come from new versions

   Minor Changes
   * All examples of RR records now use SPF2 RR type, not TXT
   * Added IANA request for new RR type
   * Fixed the value of IPv6 examples to conform to RFC 3849

	- Mark

Mark Lentczner
http://www.ozonehouse.com/mark/
[email-masked]

---

From: Roy Badami <[email-masked]>
Date: Sat, 14 Aug 2004 00:21:40 +0100

>>>>> "Mark" == Mark Lentczner <[email-masked]> writes:

    Mark> draft-ietf-marid-protocol-01 has been submitted. 

Any chance of posting a pointer (or just posting the text) so we don't
have to wait for it to show up in the ID archives?

     -roy

---

From: Mark Lentczner <[email-masked]>
Date: Fri, 13 Aug 2004 16:42:04 -0700

> have to wait for it to show up in the ID archives?

Hope this doesn't get me in trouble....  Here is a link to the HTML 
version:

	http://www.ozonehouse.com/mark/protocol-01.html

Note: The version published by the internet-draft editor should be 
considered official, not this.  They should be the same, only the 
official one is in text format.

	- Mark

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 14 Aug 2004 12:09:04 +0200

Mark Lentczner wrote:

>    * Added back %{p} macro that was removed in last rev

BTW, %{t} is defined to be a "timestamp in UTC epoch seconds
notation" and only used in exp= explanations.  That's meant
to be human readable (as error message copied into a bounce),
so why not use a ISO 8601 timestamp ?

                          Bye, Frank

---

From: Meng Weng Wong <[email-masked]>
Date: Sat, 14 Aug 2004 11:15:23 -0400

On Sat, Aug 14, 2004 at 12:09:04PM +0200, Frank Ellermann wrote:
| 
| Mark Lentczner wrote:
| 
| >    * Added back %{p} macro that was removed in last rev
| 
| BTW, %{t} is defined to be a "timestamp in UTC epoch seconds
| notation" and only used in exp= explanations.  That's meant
| to be human readable (as error message copied into a bounce),
| so why not use a ISO 8601 timestamp ?
| 

it's not meant to be human readable; it's meant to give a
hint to the explanation CGI.  for example, the cgi could
read the time and bring up a custom response that says
"sorry, our mail system was misconfigured last sunday and
that is why you got the error message, please ignore it."

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 17 Aug 2004 03:24:15 +0200

Meng Weng Wong wrote:

 [about %{t} timestamps]
> hint to the explanation CGI.

Okay, it's for explanations by URL, that makes sense.  Maybe
mention it in an example.  I'd still prefer the format...

| The syntax is: YYYYMMDDhhmmssZ
| Example: 19990609001326.34352Z

...as in RfC 3161, but if you're sure that the CGI knows all
about 20380119031407Z (RfC 2626), the timestamps should work.

I'll look into the new ABNF of protocol-01 later.  In the new
SUBMITTER-03 bounces can still go to an unchecked MAIL FROM,
so that's not yet in a state where I could consider it to be
"compatible" with SPF classic.

PRA-00 is almost the same algorithm as before, so it does not
yet handle the common "missing Sender:" case.  The "MAY" in
2476 8.1 still exists in draft-gellens-submit-bis-00.txt 

The PRA algorithm without a solution for the "missing Sender:"
problem on the side of the PRA-aware recipient won't work.

Mail providers can't publish a SPF2.0/PRA sender policy, if
this doesn't work with legacy MUAs + 3rd party "MAYbe not" MSAs
of their users.

SYMPA lists:  They have an Errors-To: matching the Return-Path:
But a special Errors-To: PRA-step for SYMPA makes no sense, a
general "missing Sender: derived from Return-Path:" PRA-step
would work for everybody.
                         Bye, Frank