Subject: [lemonade] delta times in FUTUREDELIVERY and time zones

From: Antony Bowesman <[email-masked]>
Date: Mon, 16 May 2005 11:10:55 +0100

A couple of commnets

1) The specification takes no account of time zone differences between 
client and server.  As a result, with differing time zones, none of the 
use cases given in the introduction can be guaranteed and using future 
delivery as a personal reminder service is, at best, unreliable.

RFC2852 gives some justification for its use of delta times against 
server side locale specific time to calculate the delivery by time 
although this justification seems weak.

The future delivery abstract states

a. "... client indication of future delivery time"
b. "...an appointed time in the future"
c. "...delivery at an appointed time "

The client decides a based on its own TZ, the MSA decides b based on its 
TZ and c indicates a "DELIVERY AT" specification which conflicts with 
the effective "DELAY FOR" definition.

While everything is OK if both client and MSA are in the same TZ, it all 
gets messy if not.  MSAs are particularly useful for mobile submission 
to corporate mail systems and by its very nature, this use case 
introduces more chance of TZ mismatch.

Although there are implications for a client implementation, would it be 
better to require the delta time be relative to current UTC for both 
client and server.  That would allow the server to honour the request as 
given by the client rather than introducing a potentially random 
mismatch between the two.  An MSA can be injecting messages to any 
number of servers in different time zones.

An alternative would be to make this a "DELIVERY AT" extension and use 
date-time specification for delivery time with MAIL FROM... AT date-time.

Otherwise, there should be a discussion of TZ factors and how mismatches 
can occur.

2. Section 4.2.1

<quote>
1) When an MSA generates a DSN...
</quote>

Should be "If...".  There's no guarantee the MSA is making final 
delivery.  Same for 2)

Regards
Antony

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Mon, 16 May 2005 09:46:09 -0500

The delta time was choosen exactly to address the time-zone issues.  There is no machinery for indicating timezones between senders, receivers, and potential recipients.  Delta time works because ten minutes from now is ten minutes from now everywhere.  The client indicates it wants a message released to the network in ten minutes, the server releases it to the network in ten minutes.

Now, if you want the message sent at 10:00AN local time, and it is 8:00AM local time now, the client should compute that the message should be sent in two hours... So, if it is 11AM local time where the server is, the server will release the message at 1:00 PM, the right thing happens.
 
Any fancier "release at 10:00 in his timezone" calculations have to be done at the client with local knowledge of what timezone the recipient is in.  This feature is not intended to solve that problem.  There is no way for the submission MTA to know the timezone of an arbirary recipient.  This extension does not place obligations on a final-delivery MTA which may have that knowledge to implement the feature.  (Various denial-of-service attacks are possible if the future-delivery storage is outside the senders administative domain)

Greg V.

-----Original Message-----
From: Antony Bowesman [mailto:[email-masked]]
Sent: Monday, May 16, 2005 6:11 AM
To: [email-masked]
Subject: [lemonade] delta times in FUTUREDELIVERY and time zones

A couple of commnets

2. Section 4.2.1

<quote>

Regards
Antony