mouss wrote: >Philip Prindeville a écrit : > > >>I'm curious to know how the message could have been routed and delivered >>without ever getting an Message-Id: stamped on it... >> >>Sendmail, for instance, will always add a message-id if one isn't present, >>regardless of whether the message is being submitted locally via a pipe, a >>file, loopback socket, etc. or whether it is being relayed on port 25. >> >> >> > >postfix too will add missing headers. but not all MTAs will, and they >are right. sendmail started in a world with too many protocols and >"weak" standards". today is different. we now prefer to stick to the >standards whenever possible. fixing broken mail has proven to cause >problems than can't be fixed. > >I personally don't like MTAs "fixing" inbound mail. it's ok to fix >outbound mail if they are used as an MSA, but even then, I don't like >that. I like to see the message that _was_sent_. > >I don't like browsers and MUAs guesses (which generally result in >vulnerabilities and/or making it impossible for a FW/proxy to block bad >things), I don't like software fixing problems that should be fixed at >their source, ... > > >
I see your point, however I don't think that Sendmail was trying to "fix" broken email. I think it was trying to take email from other transports and protocol spaces (like Bitnet, Usenet, Decnet, X.400, etc that have passed into well deserved obscurity... ;-) and add the necessary garnishments to make them transportable across SMTP/RFC-822. The issue is that Sendmail would also add these to messages being relayed from other MTA's. I guess that's the nature of the problem: SMTP doesn't give you a separate mechanism for submission and relaying. You can't easily tell if you're getting a message via SMTP from an MUA that didn't attach a Message-Id (and thank god they don't, because there would be too many different "fingerprints" of Message-id formats to tell which were bogus and which were genuine, i.e. coming from valid MUA's and not ratware)... or if you're being handed a message from a broken relay. Hmmm.... Perhaps the protocol could had a mechanism added so that the server could tell if it is talking to a peer (another MTA) or a client (an MUA). But then, would that create the potential for exploits? Probably. -Philip