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
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,
I did not like the following sentence wrt the increased length of RCPT TO
Of course, since the value could conceivably be longer than
256 characters, implementations are welcome to allot more space for
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
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.
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
and myself (ned(_dot_)freed(_at_)innosoft(_dot_)com).
Description: S/MIME Cryptographic Signature