mailing list archives

If I have a message:

FROM: Foo
to :Bar

And BODY.PEEK[HEADER.FIELDS (from to)] returns:

From: Foo
To: Bar

So it:

1) Standardizes header name casing
2) Standardizes whitespace around ':'

Any thoughts on how wrong these are?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20080216/fd61194f/attachment.sig>

Timo Sirainen writes:
> Any thoughts on how wrong these are?

Obviously ;)

It depends on what's being stored or displayed. What you see is a 
changed ASCII string representing an unchanged RFC822 header field, so 
it really depends on whether the system operates on ASCII/octet strings 
or on the objects defined by RFC822 and its successors, and on whether 
you (as user) want to operate on email messages or octet strings.

The same issue occurs with domains, which IMO is simpler since there's 
less syntax involved. Suppose you send

     From: tss@iki.fi
     Cc: tss@Iki.Fi

and one or more recipient(s) see(s) iki.fi written with the same casing 
in both fields. The string has changed, the domain hasn't. Has there 
been a change?

The RFCs touch on this stuff a few times. RFC 3501 page 46 has a note, 
the S/MIME RFCs mention it, and IIRC MIXER does, too. I haven't looked 
at vcard in enough detail, but I wouldn't be surprised to see 
something.

Arnt

On Sat, 16 Feb 2008, Timo Sirainen wrote:
> If I have a message:
> FROM: Foo
> to :Bar
> And BODY.PEEK[HEADER.FIELDS (from to)] returns:
> From: Foo
> To: Bar

There are two answers to this.

First, if what BODY.PEEK[HEADER.FIELDS ... ] returns is any different 
than what is returned in BODY[HEADER], then this is a violation of the 
IMAP immutability rule.  If the change is universal, so that it is as if 
the delivery process rewrote the headers before it got to IMAP, then there 
is no violation.

Second, it probably does not matter even though it is a violation.  It is 
difficult to imagine a client depending upon the immutability of data in 
partial header fetches, as typically this is used to augment ENVELOPE data 
for parsing and/or presentation to the end user.

Thus, IMHO, it's probably alright until such time as some client author 
complains; and such complaints are highly unlikely.  However, if there is 
a complaint, the client author would be in the right and the server in the 
wrong.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

On Feb 16, 2008, at 10:12 PM, Arnt Gulbrandsen wrote:

> Timo Sirainen writes:
>> Any thoughts on how wrong these are?
>
> Obviously ;)

Note that I'm specifically talking about HEADER.FIELDS fetching.  
Fetching the entire message, the header of the message or  
HEADER.FIELDS.NOT would show the headers in their original form. Your  
answer sounded more like you assumed the headers were permanently  
changed for all of them.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 201 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20080216/560da5ed/attachment.sig>

Timo Sirainen writes:
> Note that I'm specifically talking about HEADER.FIELDS fetching. 
> Fetching the entire message, the header of the message or 
> HEADER.FIELDS.NOT would show the headers in their original form. Your 
> answer sounded more like you assumed the headers were permanently 
> changed for all of them.

I think it's the same issue. IMO it's (usually but not invariably) the 
same issue even if the the strings are changed only by the display 
agent before display.

What matters is what the user sees. Or rather, what the user understands 
(To: tss in times is the same as To: tss in courier, say I).

Arnt

All that said, treating a header field differently in HEADER.FIELDS and 
HEADER.FIELDS.NOT sounds dubious to me. Not necessaribly wrong by the 
RFCs, but I can't imagine why it would be desirable.

Arnt

On Feb 16, 2008, at 10:39 PM, Arnt Gulbrandsen wrote:

> All that said, treating a header field differently in HEADER.FIELDS  
> and HEADER.FIELDS.NOT sounds dubious to me. Not necessaribly wrong  
> by the RFCs, but I can't imagine why it would be desirable.

I noticed that one server already does this, and started wondering  
about doing something similar. This would allow caching headers by  
header ID -> value instead of header ID -> "header: value", i.e. saves  
a bit disk space. But since most mails use the same casing for header  
names, I guess this could be done in a fully standard way by  
allocating one bit to specify "header: is in its standardized  
presentation and it's not included in the value".

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 201 bytes
Desc: This is a digitally signed message part
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20080216/17422bbf/attachment.sig>