Subject: TECH-OMMISSION: Time Phasing Rules For Records Not Included In Core and Protocol (was RE: PRA Patent: License for Display in MUAs?)

From: "Scott Kitterman" <[email-masked]>
Date: Fri, 3 Sep 2004 16:00:06 -0400

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jim Lyon
> Sent: Friday, September 03, 2004 12:57 PM
> To: Arnt Gulbrandsen
> Cc: Michael R. Brumm; william(at)elan.net; IETF MARID WG
> Subject: RE: PRA Patent: License for Display in MUAs?
>
>
>
> On Friday, September 03, 2004 at 9:46 AM, Arnt Gulbrandsen wrote:
> > What happens if a message is sent on Saturday, the sender publishes a
> > new policy on Sunday, and the recipient's MUA attempts to verify the
> > message on Monday?
>
> If I recall correctly, in the original CallerID spec:
>
> 1. If you're retiring use of an MTA, your record should continue
>    to reference it for at least 28 days after it last sent outgoing
>    mail.  and
>
> 2. An MUA must not attempt to validate messages received by their
>    org more than 28 days ago.
>
>
> -- Jim Lyon
>
Then we need to add those rules to the Sender-ID RFCs or prohibit MUA level
Sender-ID validation.

Recommend we add to core, page 8, paragraph 7.5:

   If an MUA is going to accomplish Sender-ID validation, the MUA
   MUST NOT attempt to validate messages received by their
   organization more than 28 days ago.

Recommend we add to protocol, page 24, a new paragraph 6.3:

6.3  Record Maintenance Time Requirements

   When sender policies change, it is important that old mechanisms
   not be remove prematurely.  Temporary errors between MTAs can
   legitimately delay mail delivery for several days.  Sender-ID
   validation by receiving MUAs may occur as much as 28 days after
   the message has been successfully received, see [CORE].

   Obsolete mechanisms SHOULD NOT be removed from permitted sender
   records until at least 32 days after the last legitimate use of
   the mail sender defined by that mechanism.  Earlier removal
   incurs the risk that legitimate mail will fail Sender-ID checks.

I say should not rather than may not because there are no doubt reasons that
senders might want to take the risk that mail would be lost rather than
leave the obsolete mechanism in the record.  Compromise of an MTA is one
reason that comes to mind.

32 is my uneducated guess, I welcome corrections.  I think it should be 28
days plus however long should be allowed for delayed delivery due to
transient errors.

Scott Kitterman

---

From: Mark Lentczner <[email-masked]>
Date: Fri, 3 Sep 2004 13:22:54 -0700

On Sep 3, 2004, at 1:00 PM, Scott Kitterman wrote:
> ...

I would recommend against such inclusions.  I agree that the 
information given is sound advice for system administrators.  But, the 
technical scheme is hardly dependent on following such advice, nor will 
ignoring such advice lead to any major break down.  Such language 
belongs in a How-To document, not the draft.

	- Mark

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

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 3 Sep 2004 14:00:59 -0700 (PDT)

>    org more than 28 days ago. 

That is a bad idea. First of all trying to track email and do the changes 
some time after is not an easy thing, some ISPs may not be able to accomodate.
Second there are number of references as part of SPF records to other dns
records, such as to "A" record of hosts, to MX records, to PTR, etc. All 
these may have to change lot faster and not be possible to wait 28 days.

Speaking as an ISP operator, I'm opposed to any language in the text that 
will specify time in which we have to change dns records when ips have 
already been changed or any constraints on provisioning and renunbering.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "Scott Kitterman" <[email-masked]>
Date: Fri, 3 Sep 2004 16:56:11 -0400

> [mailto:[email-masked]]On Behalf Of Mark Lentczner
> Sent: Friday, September 03, 2004 4:23 PM
> To: IETF MARID WG
> Subject: Re: TECH-OMMISSION: Time Phasing Rules For Records Not Included
> In Core and Protocol (was RE: PRA Patent: License for Display in MUAs?)

> belongs in a How-To document, not the draft.
I sort of agree, but the fundamental problem is that MUA level Sender-ID
validation is currently neither permitted not forbidden.  I think the time
limits need to be written into the RFC somewhere if MUA validation isn't
prohibited.  If their not, we will end up with disagreements about long
obsolete data should be maintained and whether or not someone's e-mail was
appropriately rejected.

I would expect that Jim's 28 days from the Caller ID spec was a surprise to
a fair number of people.  It certainly was for me.  The time frame for which
the record has to be valid is an important point.  However we want to bound
the time domain, we need to do it.  I don't propose we go back to the idea
of adding valid times to the records, that's complicated.  I do think we
need to define limits however.

The best solution, I think, would be to have the MTA add headers that the
MUA can process at leisure and prohibit direct Sender-ID validation by MUAs.
Then the time bound is limited to the times associated with SMTP processing.
Those are generally well understood.  I would have suggested that
originally, but was trying to avoid controversy.

Scott Kitterman

---

From: Yakov Shafranovich <[email-masked]>
Date: Fri, 03 Sep 2004 17:20:06 -0400

Mark Lentczner wrote:

> I would recommend against such inclusions.  I agree that the information 
> given is sound advice for system administrators.  But, the technical 
> scheme is hardly dependent on following such advice, nor will ignoring 
> such advice lead to any major break down.  Such language belongs in a 
> How-To document, not the draft.
> 

I am hesistant about not mentioning it at all since it is something that 
might come up often. Perhaps a separate BCP document can be referenced 
as part of the main draft. And while we are on that, is there a BCP 
document or is that planned for the future?

Yakov

---

From: <[email-masked]>
Date: Fri, 3 Sep 2004 17:33:56 -0400

> already been changed or any constraints on provisioning and renunbering.

Correct me if I'm wrong, but I don't see anything in the current
drafts to suggest you could perform Sender ID checks after the fact. 
I understand that *Caller ID* may have had such a stipulation.  Thus,
as I read the drafts currently being considered, it is not possible to
implement Sender ID in an MUA.  Does this mean we need a change?

I think changing the document to support Sender ID checks after the
fact would be fairly controversial, however, both with ISPs, and with
small domain owners.  If you want to do this, perhaps we need a macro
for the number days since 1970 when the message was received.  (%{t}
is currently no good because it's only for explanations, it is in
seconds, and it is the current time, not the time at which the message
was received.)

David

---

From: <[email-masked]>
Date: Fri, 3 Sep 2004 17:50:12 -0400

> Then we need to add those rules to the Sender-ID RFCs or prohibit MUA level

I prohibiting MUA-level validation is fine, so long as the MUA is
allowed to extract the validatoin result from some header.

I think that after the fact Sender-ID validation is very problematic,
and I would not like to see the changes you suggest.  However, if you
do include those changes, I would very strongly also encourage you to
make the following change to the protocol draft:

In section 7.1, between the macro explanations for p and v, include:

 u = The year, month, day, hour, and minute in UTC at which the
message was accepted by the receiving MTA, separated by periods.  The
month, day, hour, and minute fields are always two decimal digits.

In the example section (7.2), state that the received time is August
31, 2004, 12:30AM UTC, and include the examples:

%{u}     2004.08.31.00.30
%{u3r}  31.08.2004

David

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 3 Sep 2004 15:29:16 -0700 (PDT)

> implement Sender ID in an MUA.  Does this mean we need a change?

The current drafts are inprecise and I've pointed out some of the conflicting
statements in one of previous posts. The marid-core draft in introduction 
says that:
  "This document described mechanism such that receiving MTAs, MDAs
   and/or MUAs can recognize mail in the above category and take 
   appropriate action. For example, an MTA might refuse to accept a 
   message, an MDA might discard a message rather then placing it into a 
   mailbox, and an MUA might render that message in some distinctive fashion".

This statement can be understood to mean that MUAs would do SenderID check
but can also be understood that MUAs will take certain actions (displaying
verified email address, etc) based on secondary information from MTA but 
not directly do authentication. However majority of people reading above 
statement will probably understand it to mean that MUAs would do authorization
directly, so I'd like to request that this statement be changed to:
  "This document described mechanism such that receiving MTAs and MDAs can 
   recognize mail in the above category and take appropriate action. For 
   example, an MTA might refuse to accept a message and MDA might discard 
   a message rather then placing it into a mailbox."

> seconds, and it is the current time, not the time at which the message

It gets complicated, messy and leads to errors when you try to do ip
authorization after the smtp transaction and especially when you know
that serious amount of time passed from when it happened (serious is 
anything more then 1 hour and even that is too much). It is also very
difficult to standartize this behavior and its outside scope of this 
working group which is developing standard ONLY for MTA authorization
using DNS records.

The only program that has been successfull after the fact is Spamassin and 
the reason is that it does it right after message is received by SMTP 
server (within seconds usually) so there is no time interval and 
spamassasin is setup specific with MTA it works with so it knows exactly 
how that MTA will inform about which client just connected to it 
and it knows there were no other email hop in between. Nevertheless,
as I understand it, spamassasin developers prefer to move system 
where spamassasin is called directly from MTA (andthus within scope of 
mail transaction) and not after the completion of transaction. That is 
why it is now often called from sendmail milter and patches are available 
for other MTAs.

---
William Leibzon, Elan Networks:
 mailto: [email-masked]
Anti-Spam Research Worksite:
 http://www.elan.net/~william/asrg/