Re: Email Subaddressing

[Bart Schaefer <[e-mail]>]

On Aug 3, 12:56am, D. J. Bernstein wrote:
} Subject: Re: Email Subaddressing
}
} > As I said, it's inconvenience.
} 
} _What_ is inconvenient?

Not using subaddressing to categorize my incoming mail.

} > The interoperability problem is that the software on my Mac has to
} > support both schemes.
} 
} What for?

So it can put the right ones in the Reply-To and/or From headers based
on which ISP I'm sending through.

} I know people using subaddresses with a variety of MUAs. The MUAs all
} deal with incoming _mailboxes_, not incoming addresses. Why should an
} MUA care which addresses are owned by the user? 

To provide additional mail management features for the user.  It's not
necessary, but it's convenient.

} Yes or no: Are you having trouble sending messages?

No, but not really relevant.

} Yes or no: Are you having trouble receiving messages?

Also not relevant.  The question is not whether the message arrives, but
what happens to it after it does.

} Why should the MUA care about internal structure in the user's address?
} All it does is copy the address.

It is true that this is all that many MUAs do today.  That doesn't mean
it's the best behavior, especially for a user who has multiple addresses.

Example situations:

ISP "A" supports both subaddressing and IMAP.  I can FTP to the server
and set up a configuration file so that messages with different incoming
subaddresses end up in different mailboxes, which I can then access via
IMAP.  This is as close as things get to your model.  But my MUA can't
see the configuration file; it has to have the matching subaddresses to
fill in submitted From and/or Reply-To in its own separate configuration.

ISP "B" supports subaddressing but only POP.  All messages are delivered
to the POP mailbox of the primary address; it's up to the POP client to
spot the subaddress and categorize the messages after downloading them.
The ISP assigns only the primary address; the subaddresses are up to me
to make up.  They don't use the same format as ISP "A" subaddresses.
There's no LDA configuration file, because the subaddresses are ignored
for purposes of delivery; everything has to be configured at the MUA.
(An additional annoyance about "B" is that it doesn't give me a hook on
the envelope address, only what appears in the headers, but that doesn't
have anything to do with the address formats.)

ISP "C" supports only POP and not subaddressing, but it's where I have
my low-cost internet connection.

The goal I'm trying to attain is that messages that pass through all
three ISPs are categorized by incoming address into local mailboxes on
my home machine.  I can actually do this most easily with ISP "B"; one
remote mailbox is opened, and my MUA sorts out the messages as they are
downloaded.  (Unfortunately, it doesn't work as well as it could because
the envelope information is gone by that time.)  I can do it with ISP
"A" if I do more sophisticated remote access, opening one remote mailbox
for every corresponding local one.  I can't do it with ISP "C" at all.

In a better world, I'd have *one* subaddress configuration for both "A"
and "B", which is either part of my MUA or at least is tied to my home
machine.  I might choose to take advantage of the configuration on "A",
but I wouldn't have to.  I'd download and categorize mail from both "A"
and "B" exactly the same way, via my MUA.  And I'd contact "C" and ask
them to add support for this same common format.

As it is today, I don't make use of any of it, except for a couple of
cases on "A" that get used only when I want to send mail to my own home
address from my work.  I probably would use more if I had the envelope
address hooks on "B", because my MUA is configurable enough to support
both "A" and "B" formats; but it's still inconvenient to keep the two
configurations (MUA and "A") in sync, and that still doesn't give me
anything new in the way of leverage with "C".  And my MUA's interface on
configuring and selecting among subaddresses could be improved if there
were only one format to support, as well.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com