ietf-smtp
[Top] [All Lists]

SMTP metadata transfer

2008-05-19 04:50:01

The BATV message here got me thinking.

I can think of some potentially better solutions to the problem that BATV is trying to solve, but they would require SMTP extensions with extra data after RCPT TO, and the problem with SMTP extensions like that is that all servers on the path of the message need to support the extension for it to work properly (eg the DSN extension). This is, I guess, why BATV is implemented as hacking the return-path address, rather than the 'more correct' method of adding a parameter to the MAIL FROM command.

So, I wondered, could an extension not be come up with to allow 'metadata' to be passed with the message. At the moment we have the envelope (sender + recipient) and data. What if we could add arbitrary data to go along with the 'envelope'. So, all mail servers that support the 'metadata' extension just pass on the metadata to the next server in the path, even if they don't understand the metadata.

Then, to take the example of DSN, if the initial and final MTAs understood DSN, and everything in between understood the generic 'metadata' extension, DSN would work, even if MTAs in between didn't understand DSN.

Yes, for this to work optimally, it would require every MTA to support the generic 'metadata' extension - but it would allow new end-to-end extensions without everything in between having to support the new extensions as well, once they support the generic one.

Two extra ideas:
- potentially, it could be specified that MTAs could see that the downstream MTA doesn't support the 'metadata' extension so it could copy the metadata into the header somehow, and a later MTA could take it out and put it back in the metadata (this would need care to protect against spoofed metadata - if it mattered, which I'm not sure it would). This would lose some of the benefits - eg if the metadata is a signature of the sender/recipient, you wouldn't be able to check it at envelope time, it would have to wait until the data was received, but you wouldn't lose the functionality

- also, potentially, you could work out some way to copy MAIL FROM, RCPT TO, DATA parameters into the metadata, associated with the EHLO keyword, and automatically add the parameters into the MAIL FROM if the downstream server supports the appropriate extension.


Anyway, this is just a 'throw the idea into the ring' message - I wonder what anyone else thinks :)

--
Paul Smith

VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows

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