I can't imagine why anyone would use a signed value for this. Crazy
that all three of these clients have the exact same bug, especially
since the correct behavior is defined in the RFC. This is supposed
to be fixed in the latest version of Thunderbird (2.0.0.9), and
indeed I'm no longer getting the error message, but I'm still not
seeing the messages either. I've also filed a bug report with Apple,
and I'll do the same for Horde later.
Meanwhile, I'm figuring out how to strip X-UID headers. I use
MIMEDefang, which is designed for cleaning up these sorts of things,
but apparently it doesn't strip X-UID by default, so I'll have to add
that. While I'm at it, are there any other nasty headers you can
think of that I should be stripping?
Once I get that taken care of, how can I get imapd to go back to
using smaller values? You mentioned "the UID regime"; what is that?
Thanks for your help.
~ Andy
On Nov 19, 2007, at 4:26 PM, Mark Crispin wrote:
OK, that explains the problem precisely.
It's a bug in those poorly-written client programs (IMP, Apple
Mail.app, Thunderbird). RFC 3501 stipulates that UIDs are an
unsigned 32-bit value, but these broken programs treating it as a
signed 32-bit value.
Consider it to be punishment for not using quality software like
Pine/Alpine. ;-)
More seriously, I just filed a bug report with Apple about the
problem in Mail.app, emphasizing that it's a denial of service
program.
Since you are using the traditional UNIX mailbox format, the
explanation is this:
Some attacker (probably a spammer) sent the victim a message with a
fake X-UID header with the large value. That caused the UID regime
to bump up to the large value.
To prevent this, the tmail and dmail programs filter out fake
message metadata headers such as X-UID, but if you're still using
mail.local or whatever they probably aren't doing that filtering.
Possible fixes:
Use tmail and/or dmail to deliver mail instead of mail.local.
Use a format other than traditional UNIX mailbox format; other
formats keep the metadata out of band from the message and thus
attackers can not forge it.
-- 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
Imap-uw@u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
