I can see a legitimate argument for this sort of thing. In particular, the application for piecewise signing and encryption strike me as potentially a good idea for any mass-mailed encrypted material. However, there might be better and more tailored ways to accomplish this (like maybe as a security RFC). SLIDE does not sound difficult to implement from the server side, but I suspect that its use would have a very negative impact on server performance when network multicasting cannot be accomplished for all recipients. Maybe this is okay if we're only talking about a special multicasting class of mail server. I would not like to design the user interface for the client, though. ;-) I did not like the following sentence wrt the increased length of RCPT TO command lines. > Of course, since the value could conceivably be longer than > 256 characters, implementations are welcome to allot more space for > this purpose. This seems like it would encourage products with different capacities that could not be easily negotiated in EHLO. Some additional language is necessary in 3.2 concerning "message trimming". This sounds like it might cover support for relaying to recipients not accessable via a multicast group, however, the overall scenario for relaying is not described. There should be a description of what happens in the multicast case, and what happens if the message must be relayed to a non-multicast non-slide capable host. I think the concern about this benefiting spammers is a little overblown. I do not see anything in this draft that would cause any of the existing or planned anti-spam techniques to be circumvented. Neither does it seem likely that a spam outfit would be able to use this service extension to much positive effect. Without network multicasting to EVERY recipient host this merely shifts the load from their special purpose client to their special purpose server. Trying this out on a larger scale seems like the only way to gain some experience in how such a service extension might be used. We have comparatively little experience with multicast applications in the IETF to be making calls on the "value" of the extension. I wouldn't have any problem with this going forward as an *experimental* RFC. Chris bonattic@xxxxxxxx _____________________ ned.freed@xxxxxxxxxxxx wrote: > The IESG has been asked to consider draft-ward-esmtp-slide-03.txt, "SMTP > Service Extension for Slightly Differing Multicast Messages (SLIDE)", for > publication as an experimental protocol. Since this document describes a > SMTP extension of some complexity I'd like to get some community > feedback on it. > > Comments can be sent to the list or directly to Patrik (paf@xxxxxxxxx) > and myself (ned.freed@xxxxxxxxxxxx). > > Thanks. > > Ned
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature