38 lines
1.3 KiB
Plaintext
38 lines
1.3 KiB
Plaintext
MBOX-Line: From arnt at gulbrandsen.priv.no Sat Feb 16 12:12:37 2008
|
|
To: imap-protocol@u.washington.edu
|
|
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
|
|
Date: Fri Jun 8 12:34:41 2018
|
|
Subject: [Imap-protocol] header.fields fetching
|
|
In-Reply-To: <1203188859.4901.147.camel@hurina>
|
|
References: <1203188859.4901.147.camel@hurina>
|
|
Message-ID: <rLpAj0qCNeD2mVCkSSk87w.md5@libertango.oryx.com>
|
|
|
|
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
|
|
|