[Patches] mailbox.UnixMailbox and rfc822.Message.unixfrom

[Thomas Wouters]

On Mon, Mar 27, 2000 at 03:48:52PM -0500, Guido van Rossum wrote:

> The unixfrom feature of the rfc822 module is at best questionable --
> it it not part of the mail headers as defined by RFC-822!

I concur, but the reality is that the rfc822 modules *does* support the unix
mailbox added feature 'unixfrom', whereas the unix mailbox class in the
mailbox module *doesn't*. That's what the patch remidies.

The problem is that the unixfrom line holds information that can't be
reproduced from the other headers, currently. The address in the unixfrom
line is not necessarily the same as the one in the From: header, and the
date in the From line is the date the message was received on the local
machine, in the local timezone.

I'd be prefectly happy with subclassing rfc822.Message in mailbox and moving
the 'unixfrom' support there (marking the rfc822.Message.unixfrom attribute
deprecated) since it does make more sense, but I'm not sure if it's worth
the effort. I have a gut feeling there is a lot of code out there that uses
rfc822.Message.unixfrom.

> Why do you need access the Unix from header through the mailbox
> module?

I thought Mailman needed it. Mailman has a situation where a message gets
dumped to disk, using 'str(msg)', and it lost the unixfrom line in the
process. I tried to reproduce it by opening one of my own unix mailboxes,
and noticed that unixfrom wasn't begin set. The problem in mailman was
unrelated, but I still think the mailbox module should keep the fromline. I
could write myself a script that needs it if you wish, though :-) The point
is that the module does a fair job of representing a mailbox, but doesn't
quite make it to the finish line in this case.

The problem as I see it is this: the unixfrom line is an important part of
the UnixMailbox. Currently, after you read in the unix mailbox via the
mailbox module, you *can't* recreate it by appending the individual
messages. The unixfrom lines dont get stored anywhere in the mailbox module,
either. You have to kludge around, faking the unixfrom line by using
(possibly) the wrong addresses and the wrong date.

(The address problem could possibly be solved by transforming the unixfrom
line into a Return-Path header, like sendmail does internally, but in all
honesty I'd find that a waste of the unixfrom support in rfc822, misplaced
or not.)

> Your patch worries me: the dependency between _search_start() and
> next() through the _skipfirst variable begs for problems in
> subclasses.

And there I was, thinking it was an elegant solution to a tricky problem ;)
The only other solution I could see was overriding next entirely, in
UnixMailbox, or perhaps rewriting the msg search/skip methods... What
problems do you forsee, in subclasses ? I must admit I dont really see what
kind of problems it would cause, though I admit a warning/description at the
variable declaration might be in place.

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!