Re: Intent to revive "expires" header fromdraft-ietf-mailext-new-fields-15

Hector Santos wrote:
> The only way I see you can do this is to give it some obscure header 
> field name that 100% relates to user rendering.
>
> But calling it "Expires?"  Sorry, don't be surprise if someone uses 
> this outside the proposal intent to keep backends or operators from 
> using it.  Its too juicy.  Nothing like it exist (in email) to get rid 
> of mail with zero false positive. The sender says "On this date, this 
> message is no longer useful, valid, its useless",  rest assured it 
> will be taken literally and they are not going to wait for a user to 
> get rid of it, especially when their 3rd party offline user is not 
> prepare to support it.  Centralize systems will be the key beneficiary,
>
+1

I have no real problem with a header which says 'you may delete this 
message after this date' (IMHO, that's what 'expires' means). I have no 
problem at all with the concept of a header which says 'you may display 
this message in a different form after this date, to signify it's past 
its "best before" date', but calling that 'expires' leads to massive 
ambiguity IMHO (maybe that should be the name for it - 'Best-before: 
...' ;-) ).

You could say 'but the spec says the mail server MUST NOT delete it 
after that date' - but anyone who's been working with email for more 
than a few months should know that most people who should know better 
don't properly read/understand the standards. (TBH, if you're reading 
this mailing list, you're already in the minority of email software 
developers/admins!). How many times have you seen timeouts which breach 
the specs? How many times have you seen big ISPs have mail servers which 
either use or can't handle line endings other than CRLF? Have you seen 
POP3 servers which allow multiple concurrent logins to the same mailbox? 
(I have, from very large ISPs - in breach of the standard, with very 
confusing consequences). Many people read standards and then treat 'MUST 
NOT' as 'SHOULD NOT', 'MUST/SHOULD' as 'MAY', 'SHOULD/MAY NOT' as 'MAY' 
etc.  Let's not give them another gun to shoot themselves with.

-- 
Paul Smith

VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows