>From: "Peter Samuel" <[EMAIL PROTECTED]>
>
> Have a good long read of RFC 821. You must accept the entire message
> before you can examine the content, no matter what you use as your SMTP
> daemon. You can _only_ do envelope filtering in an SMTP transaction. Once
> you begin to accept the data you MUST accept all of the data.
I think we must interpret:
"The DATA command should fail only if the mail transaction
was incomplete".
differently. Why would the failure codes be defined if you aren't
allowed to use them? Sending my server a mail message containing
a recognized virus is always going to fail because it will choose
not to complete the transaction for good reason. Using sendmail
with MimeDefang as a milter allows this choice to be made at
the right time instead of becoming obligated to construct and deliver
a bounce message.
> To quite Dan Bernstein, qmail's author, "Profile, don't speculate".
> You may think it is inefficient to send messages to single recipients but
> have you proved it?
I'm more interested in the cost of delivery than the speed. Dan must
have different interests.
> Of 334322 messages injected, 9012 (2.7%) had more than one recipient.
A quick grep ' to=' of my maillogs on a sendmail based machine
shows 436665 deliveries, with 'from=' yielding 234917 so we aren't
quite in the same ballpark here. Many of these would have originated
on qmail based machines so initial grouping would have been
even higher.
> So, the overhead is very low and the reliability is very high for this
> person. Unless you've got a delivery profile that is very different (ie
> weighted heavily on the side of multiple receipts) I don't believe
> you'll benefit greatly from an MTA that supports multiple receipts.
The places I've worked typically sent most email to lists based on
business roles and locations and generally had multiple recipients
at each location. They also very often contain large documents
and spreadsheets as attachments.
> As for traffic over low speed lines, that's a business decision rather
> than a technical decision (most of the time). If your business has a
> definite need to send lots of email then your business should invest
> in a higher speed link (I do realise this can be difficult in some
> areas, this is not a perfect world after all).
The best business decision is to use a tool that does the job efficiently.
>You do the same with couriers vs the post office don't you?
Yes, and when sending multiple items at the same time I try to put
them the same box.
> As for development of qmail - Dan doesn't announce vapour ware. He
> says he's working on qmail-2.0 but no-one knows how much has been
> done. A lot of other infrastucture for qmail-2.0 has been developed
> (most of which we ship with SME Server). Projects such as, ucspi-tcp,
> daemontools, cdb, djbdns, etc. So development is being done, just not
> the way you may want it done. I did say it wasn't a paerfect world
> didn't I?
Fortunately there are other choices - competition is a wonderful thing.
These days hardware is cheap enough that if it is inconvenient to
get exactly the set of programs you want into one box, you can
just drop in another PC with a different set beside it.
---
Les Mikesell
[EMAIL PROTECTED]
--
Please report bugs to [EMAIL PROTECTED]
Please mail [EMAIL PROTECTED] (only) to discuss security issues
Support for registered customers and partners to [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Searchable archive at http://www.mail-archive.com/devinfo%40lists.e-smith.org
