Exact match. Not showing close matches.
'[OT] compilant e-mail systems ..... was [EE]:Eagl'
Olin Lathrop wrote:
> Rolf wrote:
>> I have attached a snippet of what things look like when your mail
>> systems start 'truncating' headers. It means that the associations of
>> the mails are lost.
> I guess you are saying that the header is supposed to track the many layers
> of "threads" the message is in reply to? Seems a bit silly, although I can
> certainly believe someone cooked up a "standard" for that. In theory, the
> chain could be infinitely long. Sounds like a good solution would be to
> completely delete that part of the header. If I did things right, all that
> thread nonsense should be reset with this message.
1. Right, it tracks how e-mails interrelate.
2. Seems silly to you, not everyone.
3. It *is* a standard See section 3.6.4 of IETF RFC2822, and it was also
specified in RFC822 (the original 'e-mail' specification in 1982), and
then again in RFC733 in 1977 (the ARPA Text Messages standard), and then
before that in RFC724 (also 1977), RFC680 (1975). The References header
is not exactly a 'new thing'. As for long lines, e-mail headers *never*
had a maximum length until the latest specification RFC2822, where the
length was limited to 998 characters. While previous specifications like
RFC733 first mention that long header lines may be 'folded' for
> Each header item (field of the message) may be represented on
> exactly one line consisting of the name of the field and its
> body; this is what the parser sees. For readability, it is
> recommended that the field-body portion of long header items
> be "folded" onto multiple lines of the actual header. "Long"
> is commonly interpreted to mean greater than 65 or 72
> characters. The former length is recommended as a limit, but
> it is not imposed by this standard.
So, e-mail has been standardized for a long time. References header
field has been around for a long time.
Further, you have written e-mail handing software yourself. You should
have read each and every one of these standards, (well, maybe not
RCF2822 which was probably after you wrote your e-mail programs).
Claiming ignorance of these standards, and treating them off-handedly is
4. Yes, the chain could be infinitely long.
5. As for why you think this is a problem requiring a solution I am
unsure... the only problem is your POP3 server it seems which is unable
to handle specifications older than the web itself.
6. yes, you have effectively 'reset' the thread
No, it is broken according to RFC2822 which is the 'e-mail' standard.
>> Fixing this is of some significance, and not just for me.
> Actually I think your biggest gripe is that it breaks the way you chose to
> look at PIClist threads.
This is why it irritates me, because when you reply to messages I can't
see what message you are replying to easily. This is especially
important because you often 'snip' out important context information
from your replies. It is always important to put people in general, and
you in particular in to a context where you can make a better attempt at
understanding a person's perspective.
No, the piclist gets it wrong too. It only tracks things by subject
line... so, I will 'break' piclist with this mail by mistyping the
Right, let's see if I understand you correctly:
I have a problem with a POP3 server.
It does not affect me directly (anyway, I like to complain about other
people having lines too long that they get truncated....)
It *does* affect some other people
The one person it affects is Rolf, and he's been pestering me for a
*Everyone* who uses Nabble is a jerk, so that makes it even less attractive.
So, let's screw it up for the others too just to spite Rolf (and perhaps
the Nabble users).
Is that it?
>> Actually I think your biggest gripe is that it breaks the way you
>> chose to look at PIClist threads.
> This is why it irritates me, because when you reply to messages I
> can't see what message you are replying to easily.
But I don't care, and I'd have to do work to change it. Fix it on your end
if it bothers you that much.
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014. Gold level PIC consultants since 2000.
More... (looser matching)
- Last day of these posts
- In 2008
, 2009 only
- New search...