[ On Tue, February 3, 1998 at 10:35:46 (-0800), Tom wrote: ]
> Subject: Re: [EXIM] Maximum Message Size
>
> You offer no arguements here on why you think 1MB is "very excessive".
10MB is extremely excessive for anyone on a 28.8Kbps link. Some of my
ISP clients end up deleting user mailboxes because of only 5MB messages,
even when the client would really like to download the message they
can't (usually due to either lack of patience, brain-dead PC clients, or
both). If every user had a high-speed cable modem, xDSL link, or even
ISDN line, then this would not be an issue, but a tremendously large
portion of the Internet's e-mail users still have low-speed connections.
Further as has been said some less attractive e-mail systems themselves
croak when messages get larger than 1MB.
MIME is a great idea to handle character set conversions, binary data,
and the like, but it's a really really stupid way to do any kind of
serious multi-media, and it's definitely not the optimum way to share
large databases and such.
> I don't really care about the connectivity of other sites. If they
> don't want large mails, they can refuse to accept them. As you stated in
> a previous message, setting up an e-mail system on the Internet implies
> certain responsibilities (your wording was much better).
Unfortunately the protocols currently in all-too-common use don't allow
the receiving site (and never the recipient) to accept total
responsibility for controlling such limits. To implement them fully
would require that a site completely reject non-ESTMP connections, and
to implement them for the user would require that everyone avoid POP and
use only IMAP or something similar where control over the spool file can
be had without first downloading it.
[[You should see what 8,000 POP users over over high speed links can do
to a large and well endowed Sparc-Ultra when they all hit the POP server
every 5-60 seconds, esp. when those users inevitably learn to keep large
messages on the server. Load averages of >20 are easy to achieve with
ODS trying to max out the I/Os on the spool disk with all "remaining"
cycles. Ultimately DBMS based IMAP servers are the only solution since
such systems will eventualy have to handle orders of magnitude more
users.]]
We still need some degree of co-operation between mail administrators.
As has been clearly demonstrated already in this thread there are indeed
many common LAN-based mail systems in active use that will choke on
merely 1MB messages. Ideally such sites would filter too-large messages
at the gateway, but any co-operative relay admin should take this into
account and try to reduce the chances that his relay could become the
source of what could easily amount to a denial of service attack on some
remote mail system.
If you can guarantee that all of the recipients of mail passing through
your system are well enough connected that they won't mind receiving a
10MB or whatever message then there's no problem, but if you're running
a system that might relay mail to anywhere on the planet then you really
should consider being more considerate to your fellow postmasters.
> Critical security measure?
Too many large messages can easily crash or lock up the mail system (or
indeed one large one has been shown to crash some mail systems), even a
well designed one that ordinarily can carry enormous traffic loads
(esp. if there's alread an enormous traffic load). If you don't
consider such events a critical security exposure then obviously you're
too worried about large messages either. Unfortunately if you also
happen to run a relay site for a large group of end users (eg. if you
were an ISP), then your relay could become the source of a denial of
service attack that puts someone's mailer out of business.
Even worse some mail systems are so persistent that they can repeatedly
crash the receiving mailer as quickly as you can reboot it. We had this
happen several times at a client site where smail would almost instantly
try to re-send the message (they had requested frequent queue runs and
after a night's backlog there were *lots* of queue daemons just itching
at a chance to blast the LAN system! ;-). Unfortunately for them in
this case e-mail is a critical part of their world-wide 24x7 support
network, though I don't think they've yet pointed the blame where it
belongs on the wimpy LAN system.
> What background are you from? It doesn't seem that you've worked
> on a significant real-world mail system before.
I thought this mailing list was above such things..... ;-)
I've run several dozens of large and small very real-world e-mail sites,
and given professional advice to even more, over the span of nearly a
dozen years.
> But why break the message into parts? It is just more work for the same
> affect. In fact, one large message is better because it imposes less
> overhead and results in less mail to handle. I'd take 100 1MB message
> over 1000 100KB messages anyday.
As I said it's a last option for the user who simply must receive a very
large e-mail message. The overhead for the local delivery of a batched
message is actually easier on most mail systems (esp. when it prevents
it from crashing), and the overhead on the wire is still only a tiny
percentage of the total traffic. The user is still stuck with a whole
heck of a lot of data in his mailbox, and if he used POP he's screwed
either way....
--
Greg A. Woods
+1 416 443-1734 VE3TCP <gwoods@???> <robohack!woods>
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>
--
*** Exim information can be found at
http://www.exim.org/ ***
