hey mark, thanks for the quick response and for taking the time to explain the relevant issues. i have a couple more comments/questions below (mostly just for my elucidation.) thanks again for your time. ed
On Mon, Jan 29, 2007 at 03:16:54PM -0800, Mark Crispin wrote: > Hello Ed - > > I appreciate your asking. I regret to say that the answer to your > question about Content-Length support is "no". > good to know. > I'm not certain how aware you are of the reasons for the objections to > Content-Length. These objections are technical, not religious. > > An example of a religious issue would be "maildir is the best (or the > worst) possible mailbox format." There are numerous intelligent people on > both sides who can present valid arguments to shore up their church. > > Content-Length, on the other hand, represents a security hole. I declined > to open that hole years ago, in the good old days before Internet security > was a major consideration. I won't do so now. > > For a while (years ago, when I was younger and less responsible), I amused > myself by inserting > Content-Length: 314159 (believe this at your own risk) > into the headers of my outgoing messages. At least one version of Sun's > mail tool would core dump. > he. nice. fyi, mailtool was eol'd a long time ago. unfortunatly for admins it's curse is still around since there are lots of archives with mailtool generated mails still around. i also know some people that still use mailtool... it's these times i think that solaris application backward compatability forever promises isn't such a great thing. ;) > Even if the application does not core dump when presented with a > ridiculous Content-Length, the problems go deeper. An application which > uses Content-Length implicitly depends upon the MDA (Message Delivery > Agent) to filter out any incoming Content-Length and to regenerate the > header with a correct Content-Length. Any path that allows the delivery > of messages with a spurious Content-Length allows an ill-intentioned > message sender can manipulate the messages that the recipient sees. > so from my perspective, i trust my MDA (sendmail + mail.local) and would consider any failures in the MDA wrt regenerating the Content-Length header to be treated as high priority MDA bugs and not imap bugs. so is your concern here that other MDAs might not filter out or regenerate correct Content-Length header entries and hence you feel that UW imap needs to propect itself againt them? also, i'm not very familiar with other mail delivery paths and hence the impact they may have on my security. it seems that from a security perspective the only mail delivery paths i would ever need to be concerned about are ones where a user (or an anonymous entity) can deliver mail to another user. (which afaik always goes through the local MDA.) could you provide some examples of other mail delivery paths so that i could better understand the security implications? > More importantly, the attacker can manipulate what the recipient does NOT > see. I once demonstrated how an attacker could cause a message to be > lost, even when there was code to recognize an incorrect "landing" and > disregard the Content-Length. It just required the attacker to monitor > the victim until the to-be-lost message was delivered, and then deliver > the right sized suffix to set up a good "landing". > so is this type of attack possible with an MDA that correctly regenerates Content-Length header fields? > Fortunately, there is a way to remedy these problems. That way is to > include the -E flag to the Mlocal rule in sendmail.cf. This remedy is > discussed both in the UW IMAP FAQ and in the UW IMAP BUILD file. > > Please refer to: > http://www.washington.edu/imap/IMAP-FAQs/index.html#7.26 > for more information. > > I'm sorry that this is unhelpful. Sadly this is one of those cases where > being helpful to a relatively small constituency would have severe > negative effects on a much larger constituency. > > In my opinion, it remains far less costly to add the -E flag and deal with > the relatively few cases of legacy mailboxes with messages (forwarded by > Sun's mail tool) that had an embedded "From " line. Note that UW imapd > only treats a line as a "From " line if it is in proper "From " line > syntax; a text line which happens to begin with "From " is not matched. > this option is on my list of possibilities, it's just further down the list since it has a larger impact on my user community. > -- Mark -- > > http://staff.washington.edu/mrc > Science does not emerge from voting, party politics, or public debate. > Si vis pacem, para bellum. _______________________________________________ Imap-uw mailing list [email protected] https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
