Part of this discussion is just plain bizarre.
It is worth remembering that SMTP is, in most respects, simply FTP reworked.
In many ways, HTTP is FTP badly reinvented.
But for a little extra SMTP handshaking at the start, there is no efficiency
difference in transfer rate between SMTP and FTP. Probably the same is
true for HTTP though I've not looked.
The one major difference, these days, is that EMAIL is often relayed over
multiple SMTP hops while FTP and HTTP are not. So there are some queueing
issues.
Craig (who not uncommonly gets 50 MB emails)
Craig Partridge wrote:
Part of this discussion is just plain bizarre.
It is worth remembering that SMTP is, in most respects, simply FTP reworked.
In many ways, HTTP is FTP badly reinvented.
I disagree - HTTP is more firewall/NAT friendly, and has no active/passive mode.
But for a little extra SMTP handshaking at the start, there is no efficiency
difference in transfer rate between SMTP and FTP. Probably the same is
No, there is overhead in encoding of binary data for transmission by SMTP.
true for HTTP though I've not looked.
Jan
It is worth remembering that SMTP is, in most respects, simply
FTP reworked.
In many ways, HTTP is FTP badly reinvented.
But for a little extra SMTP handshaking at the start, there is no
efficiency
difference in transfer rate between SMTP and FTP. Probably the same is
true for HTTP though I've not looked.
I think you missed the fact that sending files via SMTP is incredibly
inefficient. Any files sent via SMTP have to be encoded which can balloon
the transmission up 30%+. That is an incredible waste of bandwidth on a
10MB file. Also, remember that SMTP usually relays, so the message is
bounced between 1-8 servers along the way (or more), more bandwidth and
resources wasted. *sigh*
>
> But for a little extra SMTP handshaking at the start, there is no
> efficiency
> difference in transfer rate between SMTP and FTP. Probably the same is
> true for HTTP though I've not looked.
I think you missed the fact that sending files via SMTP is incredibly
inefficient. Any files sent via SMTP have to be encoded which can balloon
the transmission up 30%+. That is an incredible waste of bandwidth on a
After all, nmodep compress it back to the original size while transferring. The
rate loss is 5 - 10%, not 30 - 40.
For LAN, this volumes are not large (1 - 2 Mb).
Craig Partridge wrote:
It is worth remembering that SMTP is, in most respects, simply FTP reworked.
In many ways, HTTP is FTP badly reinvented.
But for a little extra SMTP handshaking at the start, there is no efficiency
difference in transfer rate between SMTP and FTP. Probably the same is
true for HTTP though I've not looked.
Perhaps there is no inherent difference in throughput, but the files are
necessarily larger when sent through e-mail, as they must be base64
encoded.
There's no *inherent* reason they *must* be base64 encoded. Please note
that all the way back in RFC1341, in addition to a CTE of 'base64', there's
the '8bit' and 'binary' CTEs. Sendmail started having sane support of '8bit'
way back in 8.7, in 1995. RFC3030 defines the BDAT extension for SMTP.
Now, the major real-life reason why encoding is needed is because
Sendmail 8.12 still doesn't have BDAT support. If there's sufficient
real-world demand, it's probably implementable fairly easily (a quick
readig of RFC3030 and the Sendmail 8.12 source doesn't pop out any
astounding show-stoppers)...
If there's a lot of demand for it, I'll see what it would take to get
it onto the Sendmail 8.13 feature request list....
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech
Besides interoperability concerns with current software that will have
to become 'legacy', you will open the gates to any hacker and script
kiddie that can now mail you their favorite virus, trojan or worm just
as is was compiled. It's bad enough that unprintable characters and
buffer overflows in the header must be neutered. Scary stuff that you
haven't even thought of could happen with 8 bit message bodies...
--Mitch
NetSide
FUD. Complete and total FUD.
There's *NO* change in what can be transferred. The ONLY difference is you
can avoid converting it to base64 at the one end and then decoding it at
the other end. If you haven't noticed, viruses, trojans, and worms are being
transmitted just as were compiled, via the *current* infrastructure.
And the need for neutering characters in the header was recognized in
RFC1342, 10 years ago.
And 8 bit message bodies have been supported by Sendmail since 8.7,
all the way back in 1996. The only thing that BDAT buys you over the
currently existing and *widely* deployed 8bitmime support (where Sendmail
will even automatically upgrade/downgrade from 8bit to 7bit using either
quoted-printable or base64, on a configurable basis), is that 8bitmime
is still bound by the 1000-char line length restriction in SMTP, where
you need a CR-LF pair at least every 998 characters.
BDAT doesn't open any exposures other than programmers that can't get
a length-data encoding right. Hmm.. maybe we *should* worry... 
Hmmm, I'm looking at an encoded snowhite message body right now. midgets.scr
encoded in base64, and transmitted as an attachment. Can provide you a
copy in private if you want to take it apart (but not on a PC, or you'll
get a *huge* surprise
All others in that family that I looked at were also encoded. Did anyone
get a raw binary via regular email?
--Mitch
NetSide
Hmmm, I'm looking at an encoded snowhite message body right now. midgets.scr
encoded in base64, and transmitted as an attachment. Can provide you a
copy in private if you want to take it apart (but not on a PC, or you'll
get a *huge* surprise
Notice the surprise isn't when your broken MUA decodes it from base64 to
binary. The surprise is when your broken MUA then takes that binary and
does something stupid with it.
All others in that family that I looked at were also encoded. Did anyone
get a raw binary via regular email?
And if you pay any attention - it's *NOT* the base64 decoding that protects
you from these things - it's HAVING AN MUA THAT ISN'T STUPID ABOUT RUNNING
EXTERNAL CODE.