RE: SMTP and multicasting

Jacob,

Sorry for the delayed reponse.  I've been busy doing stuff for
which I actually get paid.  ;-)

Jacob Palme <[email protected]> wrote:

> For a mailing list, multiple transmissions across the oceans
> can be avoided by having sublists in each continent. But 
> setting that up can be complex. There are also meessages with 
> multiple recipients which are not sent via mailing lists.
> 
> SMTP allows one copy of a message to be sent across the oceans,
to a 
> single MTA in each continent which then splits the message to
multiple 
> recipients on that continent.

This isn't really what I meant.  I would term this application
relay with traffic splitting.  It is functionally quite similar
to what I mean by multicasting, but at the wrong layer.  Assuming
that all the recipient mailboxes aren't on the same machine, at
some point in the SMTP delivery path the message will reach a
mail server at which the message will be copied and send n times
for n recipients.  Each transmission will be over a separate
unicast, connection-oriented transport association.  This is the
just an artifact of the design of SMTP, which is effectively
bound to TCP port 25 (and is constrained anyway by the dialog
nature of the protocol).

What I meant originally was that it would be very effective, in
some environments, to have the e-mail exchange protocol (whatever
it ends up being) have the property of being able to be run over
IP layer multicasting.  This would effectively mean that the
protocol would need to run over UDP (or perhaps some flavor of
RMT), and handle acknowledgement via separate unicast UDP, RTP,
or even TCP associations.  This has enormous potential in
environments (such as satellite wireless) where there is a common
broadcast-based data link.  When SMTP splits that message at the
last common server, it still makes n separate TCP transmissions
of the message over the common broadcast data link.  If the
protocol were mappable onto IP multicast, only one transmission
is required.


> This was common practice until the middle of 1990's,
> when all MTA owners were forced to prohibit such split because
the 
> facility was misused by spammers.
> 
> If we can find some way to stop spammers from misusing
> this facility, a new e-mail system could open up this
> useful facility of SMTP again.

[SOAPBOX]
I am one of what is perhaps a small minority who believe that the
e-mail industry has  dealt poorly with the spam threat.  We (the
Internet) have instituted a lot of halfway measures that have
been largely ineffective at stemming the tide, but which have
caused a lot of pain and angst among users.  Every try traveling
and plugging your laptop's e-mail into local service providers?
IMAP works okay, but submitting with SMTP is a pain.  I STRONGLY
BELIEVE that there is sufficient imagination in the community of
e-mail engineers to enable recipients or recipient domains to
reliably reject spam if they so choose WITHOUT BREAKING the
e-mail infrastructure.  Open relay was never the problem.
Mailing lists were never the problem.  Yet we tooks steps to
hobble both.  Control over WHO recipient domains will elect to
receive mail from IS THE PROBLEM.

I suggested an e-mail protocol binding for IP multicasting way
back in 1997.  Somebody (Keith when he as APP AD, I think) told
me this was effectively a non-starter because of the spam issue.
This is not the right way to address the problem.
[END SOAPBOX]

Sorry to rant, but anti-spam efforts are one of my hot buttons.
I've actually reigned this in quite a bit.

Regards,
Chris