At 00:37 08/05/2002 +0000, D. J. Bernstein wrote:
Eric A. Hall writes:
> Secondarily, some of the recipient-specific
> fields can't be implemented as shared header fields
Have one field for each recipient, naming the recipient:
Notice-Requested-Upon-Delivery-To: ehall(_at_)ehsco(_dot_)com
What about BCCs? Also, I think the "guaranteed" 'some response' of DSN is good.
OTOH, it wouldn't be impossible to extend DSN (EDSN?) to make it 'wrap' a
DSN request into the header the first time it sends back a 'Relayed'
notification. Then when a EDSN-aware MTA receives a wrapped DSN header it
re-creates the DSN envelope information
So, you have something like:
MUA (DSN aware) - adds DSN envelope info
MTA1 (DSN aware) - receives, and passes on DSN info
MTA2 (EDSN aware) - receives DSN info, sees that MTA3 doesn't know
DSN so creates a 'DSN-Info:' header with the DSN information encoded into
it (not difficult to come up with a schema for doing this). Also sends back
a 'relayed' notification with text indicating that 'DSN may be resumed at a
later hop'
MTA3 (not DSN aware) - receives message with DSN-Info header. Since it's
not DSN aware it just ignores the DSN-Info header and passes it on
MTA4 (EDSN aware) - receives message with DSN-Info header. Recreates
the DSN info in the envelope and removes DSN-Info header. (Optionally sends
back a notification saying that this has happened)
MDA (DSN aware) - receives message with DSN info in header and acts
on it, sending back success notifications.
Comments?
Paul VPOP3 - Internet Email Server/Gateway
paul(_at_)pscs(_dot_)co(_dot_)uk http://www.pscs.co.uk/