Dave Kitabjian wrote:
>
> Regarding: http://web.infoave.net/~dsill/lwq.html#multi-rcpt
>
> Dave S,
>
> I'm having trouble accepting this logic. You mention 3 options:
>
> "Say you're an MTA, and one of your users sends a message to three
> people on hostx.example.com. There are several ways you could do this.
>
> 1. You could open an SMTP connection to hostx, send a copy of
> the message to the first user, send a copy to the second user, send a
> copy to the third user, then close the connection.
> 2. You could start three processes, each of which opens an SMTP
> connection to hostx, sends a copy of the message to one of the users,
> then closes the connection.
> 3. You could open an SMTP connection to host, send a copy of the
> message addressed to all three users, then close the connection. "
>
> and that qmail uses option #2. Clearly, the rank of efficiency is, from
> best to worst,: 3, 1, 2
You have analyzed the situation (or part of it at least) correctly.
Thing is, Dan optimized for SECURITY not EFFICIENCY. There exists or
may exist a class of broken MTA which cannot process multiple receipts
correctly; or which leaks bcc information during a multiple receipt.
I wrote some code that pre-invokes qmail-remote, feel free to give
me credit when you use it, it is at
http://www.davidnicol.com/qmail.html
and I will be revising is as needed (into its own file most likely)
Before I patch qmail-smtpd to do essentially that preprocess when
there are multiple recipients, instead of whatever it normally does,
somebody talk me out of it?
My thought is, if mail only gets into the queue after it has
been attempted once, then mail in the queue has already failed at
least once and properly should be attempted in trickles. And also
Chris Hardie writes:
> Clearly it's a complicated issue, but it seems that as broadband access to
> the net becomes more common, businesses are going to expect to be able to
> use one "interface" to do all their communications, be it plain text
> messages or large multi-megabyte file transfers. I cringe every time
> someone sends me a 7 MB mail message, but it's difficult to explain to
> them why this is a bad idea.
>
> I'd be interested to hear if anyone's found a good general solution to
> this in a production/business environment.
One approach might be to rig the MTA to unpack attachments, give them
unique and secret file names, store them in per-user directories
where a http server on the MTA host can see them (but not server directory
indexes) and replace the attachments with links to the files. This
would have the effect of server-side-selecting the "view attachments as
links" option present in some MUAs.
Fine-grained administrative control could be asserted over how much
space in e-mail attachments you may have before the last used gets
cleared to make space, and so forth. This is what Scott Gifford
suggested, although he wanted to add password-protection instead
of giving unique, random file names.
__________________________________________________________________
David Nicol 816.235.1187 [EMAIL PROTECTED]
"Lord Macbeth knew he was approaching the SITE of the rout
from the SIGHT of odd body parts scattered on the blasted heath."
