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>
|
- SMTP metadata transfer,
Paul Smith <=
|
|
|