<<< Date Index >>>     <<< Thread Index >>>

Re: Threads and &



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Friday, June 19 at 06:33 PM, quoth Rocco Rutte:
> My point was about the _first_ MTA only. Later MTAs in the delivery 
> process are not allowed to make these changes as per RFC5321:

Ah, that's a new one I'm not familiar with (heh - came out this past 
October).

>   These changes MUST NOT be applied by an SMTP server that provides 
>   an intermediate relay function.

Interesting. I guess the question then becomes: how does a server know 
that it's the FIRST relay?

> Even if the messages comes in through SMTP, a server could check the 
> presence of Received: headers to determine if he's the place where 
> delivery starts.

That's a good heuristic, but I don't think that that's definitive.

Technically, it would appear that SMTP servers are forbidden to even 
"inspect" the headers by section 3.6.3 of RFC 5321:

     As discussed in Section 6.4, a relay SMTP has no need to inspect
     or act upon the header section or body of the message and MUST NOT
     do so except to add its own "Received:" header field (Section 4.4)
     and, optionally, to attempt to detect loopin in the mail system
     (see Section 6.3).

Of course, that prohibition against inspecting header fields is nigh 
unenforceable, and seems pretty silly.

But I think we're getting pretty far afield here. :)

> I can't see any major problems either... it's just that I think mutt 
> shouldn't mangle messages. On the other hand, I've never even tried 
> to link to message without and ID. Maybe also the implementation 
> isn't that easy because you have to change two messages, I don't 
> know.

That's what I figured. I suppose another way of putting it is: since 
it's entirely possible to receive a message that does not have a 
Message-ID header (e.g. an email server that obeys RFCs 821 and 2821 
but not 5821... particularly since only 821 has received the STD 
designation, this is something that should be planned for), the 
question becomes: what should mutt do when asked to link one such 
message to another? Even if the answer is not "alter the parent 
message to give it an ID" (because that's too hard, or whatever), the 
answer (at least in the short term) should probably include "display 
an appropriate and intelligent error message". Mutt should most 
certainly NOT "pretend" to link the messages, only to have them 
unlinked again the next time the mailbox is opened.

~Kyle
- -- 
If I had been married earlier in life, I wouldn't have seen the double 
helix. I would have been taking care of the kids on Saturday. On the 
other hand, I was lonely a lot of the time.
                                                        -- James Watson
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!

iQIcBAEBCAAGBQJKO+3PAAoJECuveozR/AWeESkP/0/+2jvEYZFuC+d62cMeKWb0
iBSfjoEqBP5SG+BEH0rcdc5HTWA0sds/K36DCMgAvkHRPN9sDva6Fj9dSusKzWdC
oj9K4msfVNmPubMzouBF/s7P1RZBC+Vd6qk5Xri3APK8DaEa/8UmFgkn57HQ7kJr
8txCYW8LQvRgy0bFjqyIVlRZQ2qgKjvAuWUQNWhzbkGvh6Ielf0WMMq+huuHdkqz
zS0ORNpRrKTV6baE4skl8qs7jta1ld/JYdExSVGjhfkvFMcXj9m4pKyfeICX/llT
Qh08D77YlaPRFqxOxNA6gWRmLcGwFRZoa0bSMqLGDqz/9Z1a2wP1w0t17H4fI0VG
Qaf371JVMBfZC3U2wQ5+8jv3Xv0T+86qDja9qnHOv0eQnBPtzZxXeBugeDNhuJ9L
MTGCjyUXn/lE+8UX0r8+ER1rjkc1/m9Cb09xWMiovOkFhBpRdItO8ZJd9br0rEd3
M3t0JBtb06nXkpDus5guRvF1EhB8o6B42o4FuuSH8DG3v9SPIe9jVwTp5eN79V9i
B1E0VaiJFyPbCx6DxwI0gRvGRlDfNU9l3nN0QlQBgrbhswDL4AbAMYMVKtz0avjo
sgxLoaThLMRlW8sD16oJYiq/ZoLBoKQegrtIFxqlwAMscqFoNvwlF2SOkP3ufK27
9coR9ZBiWJiSdzVNjJ2C
=2PZB
-----END PGP SIGNATURE-----