I remain to be convinced that problems handling large messages have
much if anything to do with the modern ESMTP protocol. It seems to me
that it has a lot more to do with implementation and deployment.
Amen!
A few observations:
Many places depend on mailers which operate as 'parallel to serial' gateways
taking apparently decoupled, asynchronous mail submission and queueing them
into a single linear pass. Therefore while the size of an object for the
submitter has no apparent 'cost' in delay terms, if more than 1 hop exists
between the sender and recipient, then for disinterested third parties there
can be quite substantive issues:
o big mail delays other peoples service
o big mail impacts on service providers in the wider sense who have
no 'contractual obligations' or SLA/QoS signoff with the sender or
the recipient.
End users have a low conciousness of list size. Therefore sending large
attachments to 'mail' can mean a n->oo expansion (ok, not infinity, but
certainly better than 2*n expansion) of data in flow. This has to be set
against sending a 'pointer to pickup' which will only cause m*n expansion
based on <total list size actually caring, and fetching the data, coupled
to any cache effects for local recipients who are lists, or otherwise can
optimize the fetchpath.
o you can't easily track or manage the inefficiencies of sending
large mail to lists
o the scaling effects of sending attachments to lists and of
choosing to preference pointers to objects are pretty directly
(inversely?) related to each other in their effect on the network
Bandwith may be getting fatter for some people, but since the total population
on the net is growing worldwide, the distribution of users to bandwidth is
not shifting up the scale at the same rate (modem speeds are lumpy increase,
post-modem access is mired in issues worldwide so its not all cable yet etc)
therefore for a priviledged few @work or @home senders, the cost of submitting
is out of all scale to the cost of reading.
o you can't easily constrain the receiver GUI to avoid d/l of large
objects so you can predict for a list that some % of recipients
are going to be screwed by an apparently benign act
o intermediate mail systems like HotMail impose size limits as a
function of scaling management and commercial imperitives, so
you have a really nasty DOS attack here by blitzing the naieve
with content. This one is real: I support a user on the MPEG
standards track and she lost all mail by (a) going offsite and
(b) .forward-ing to hotmail and (c) being mailed large attachments
from the standards bodies
I think this is about education AND operational deployment:
o Internet driving licences may seem a bit naff, but there
is value in requiring people to migrate to a power-user
status by at least trying to teach them that there are
consequences to using tools in distributed communications
o If there are simple, deployable codechanges which can make
mailers drop in a {reference to object} in place of
{entire content of object} then there is a really really
good reason to try and deploy them.
o There probably is an 80:20 rule here which can be thought
up and promulgated like:
If you know its going to less than 10 people and you
know the datapaths, you can do risky things but if
you think it may go to 100 people and you don't know
who they are, its better to be cautious
o Coupling mail-to-web for archive encourages people to shift
from direct mail access to web is viable for catchup which
leads naturally to using the web as the REAL data repositary
and using mail to point to it. In a short while, you can maybe
shift some practices to 'its easier' instead of 'they require it'
Actually, I think the best example I know of the 'right way' is the
old 'new RFC' email Joyce Reynolds used to post, which had the two variant
MIME attachments for fetch it via FTP and fetch via the web. We just need
more people to be that sensible!
cheers
-George
--
George Michaelson | DSTC Pty Ltd
Email: [EMAIL PROTECTED] | University of Qld 4072
Phone: +61 7 3365 4310 | Australia
Fax: +61 7 3365 4311 | http://www.dstc.edu.au
