ietf-822
[Top] [All Lists]

Re: Dreaming about replacements (was IDN (was Did anyone tellMicrosoft ye

2002-05-07 08:30:05

At 09:44 07/05/2002 -0500, Eric A. Hall wrote:
Paul Smith wrote:
>
> At 10:43 04/05/2002 -0500, Eric A. Hall wrote:
> >DSNs with NOTIFY=SUCCESS are an obvious example. The only thing I care
> >about is that delivery succeeds, meaning that this is a negotation
> >between the originator and the delivery server.

> Well, the OBVIOUS answer to that, is to take the DSN information out of
> the envelope and put it into the header.

Couple of problems with that approach. First is that delivery servers
would have to start poking through the headers of all incoming messages
just to find out if the message required a delivery receipt.

Hmm, most servers seem to poke around in headers in any case, so checking for a particular header wouldn't be that much more difficult.

That's a lot
of work in contrast to simply being told to do so, as with the current
model of envelope extensions.

Really? Would it more difficult than poking around in a 'blob' of extra envelope data?

Secondarily, some of the recipient-specific
fields can't be implemented as shared header fields, as they would affect
all of the recipients. Which of the dozen Original-Recipient header fields
is for me?

Agreed - but do MUAs regularly ask for different notify parameters for different recipients.

(I'm not suggesting that the current DSN system should be dumped in favour of putting the information in headers, I'm just saying that if the current failures of DSN are being used as a reason to break all existing code, then there are other alternatives which could be used without any disruption)

> does this mean that all MUAs/MTAs would have to support BOTH message
> format structures (or just the existing format..) for the forseeable
> future?

Mail readers wouldn't have to support two mailbox formats. It should be
feasible to convert 822 mails into the new format pretty simply: dump the
envelope into the envblob, dump the header section into the hdrblob, and
tag it as a legacy message. The legacy body parts should render same.

Eh?

If I use MUA 'x' and I want to send a message to a 'legacy' MTA, I'd have to generate a message in the legacy format.

If I use MUA 'x' and I want to send a message to a 'blobby' MTA, I'd have to either generate the message in legacy format (and have the MTA convert it, but not have access to any of the new 'blobby' facilities), or generate the message in the new 'blobby' format.

So, as author of MUA 'x', either I have to write code to be able to generate both message formats, or I have to accept a restricted feature set and only generate legacy messages, or I have to write an MTA with an (initially) *very* limited customer base and go for the new format only.

Also, with your 'tagging the message as legacy' suggestion (which wouldn't help the above situation), the receiving MUA would need to be able to handle messages tagged as 'legacy' as well as those which weren't.

The transition would require that delivery servers be capable of
performing conversions based on the mailbox format in case a reader is
using a legacy mail-store format.

Does this mean we'd need to have a replacement for POP3 and IMAP4 as well?


Paul                            VPOP3 - Internet Email Server/Gateway
paul(_at_)pscs(_dot_)co(_dot_)uk                        http://www.pscs.co.uk/



<Prev in Thread] Current Thread [Next in Thread>