On Sun, Aug 23, 2009 at 06:06:53PM -0400, Sam Hartman wrote: > >>>>> "Steve" == Steve Langasek <vorlon@debian.org> writes: > Steve> Qmail does not value the contents of a bounce > Steve> message. Dan documents this in a subordinate clause of his > Steve> qmail reliability FAQ. That means: if your qmail is > Steve> bouncing mail and at the same time, your system crashes, > Steve> the bounce mail contents may be corrupt or incomplete. > Steve> This sounds like data loss, which is normally considered a > Steve> grave bug per <http://www.debian.org/Bugs/Developer>. Do > Steve> people disagree that this is a grave bug? If you think > Steve> it's a grave bug, do you think it should be a blocker for > Steve> archive inclusion? > Steve, I'm not on the TC. However I do have a fair bit of experience > with Internet standards and what sorts of guarantees Internet > protocols make to their users about reliability. If you take a look > at the bottom of Page 19 of RFC 3461 you will find that an MTA is > permitted to return a partial bounce message. > While I'll admit that returning corrupted bounce messages is kind of > ugly, I'm failing to see how it could be grave if returning a message > truncated earlier would be just fine. Personally, I think that > returning corrupting bounce messages would be a bug although I would > not mind too much if a maintainer tagged it wontfix. This says that: The third component of the multipart/report consists of the original message or some portion thereof. When the value of the RET parameter is FULL, the full message SHOULD be returned for any DSN which conveys notification of delivery failure. (However, if the length of the message is greater than some implementation-specified length, the MTA MAY return only the headers even if the RET parameter specified FULL.) If a DSN contains no notifications of delivery failure, the MTA SHOULD return only the headers. So reading between the lines, in all cases, the headers of the original message must be preserved and returned as part of the DSN. (This stands to reason, as the headers will be the identifying contents that allow the sender to match the DSN up with the original message.) From <http://www.dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html> and <http://cr.yp.to/qmail/faq/reliability.html>, it's not at all clear to me that qmail handles the headers of a bounced message reliably. All it says is that "bounce message contents" are not crashproof - and the contents of a bounce message include, among other things, the headers of the original message. So I think this is either a serious dataloss problem and a violation of the RFC, or a complete non-issue, depending on which qmail actually does. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature