[Mimedefang] common practice
David F. Skoll
dfs at roaringpenguin.com
Sun Dec 7 12:34:58 EST 2003
On Sun, 7 Dec 2003, Cor Bosman wrote:
> Of the 1.9 million messages, 1.6 were sent to a single email address.
> So about 15% is sent to multiple recipients.
OK.
> But honestly, thats not
> what counts. What counts is that that 15% adds 1.1 million recipients.
> Thats not peanuts. With a lot of large lists you'd quickly explode into
> lots of queued emails, adding large delays.
I would love to see what percentage of those have more than 50 recipients.
Queueing mail does add delay, but not that much if you handle this case
intelligently.
> Customers whine if their mail gets delivered a bit later once in a while.
> If that'd be a regular thing they'd come protesting at the front door :)
> Unnecessary queueing is something we need to avoid above all.
Right. For high-performance streaming, you might want to queue the mail
in a special queue directory on its own disk (or even on a battery-backed
solid-state disk) with a queue runner that runs fairly frequently. The
"streaming" queue will always be delivered to localhost during a queue run,
so it should drain quickly and reliably.
> Once you have several hundred thousand customers the chances that
> over a 1000 of them are on the same mailinglist approach 100%.
I don't know about most mailing list software, but the software we use
(Mailman) breaks the list into manageable chunks -- it won't attempt to
deliver to more than 30 recipients at a time.
> Especially
> local lists. Hell, we see emails coming in sent to thousands of customers.
> Valid emails :)
Ouch.
> Anyways, just battling with whats best thing to do when you want to
> allow per-customer settings, including blocking, on content when you
> need to consider everything.
We need a modification to SMTP to allow this. I remember somewhere
someone proposed a CPRCPT extension (or something like that.) The
extra CPRCPT commands would come *after* the end of the DATA phase.
The idea was:
Here's a message for recipient A. And here's the DATA.
(Server replies).
OK, now send a copy to B.
(Server replies)
OK, now send a copy to C.
(Server replies)
etc...
This would allow per-recipient reply codes after the DATA phase. The
downside is that the receiving MTA needs to keep a copy of the
message queued until it is sure there won't be another CPRCPT command.
Regards,
David.
More information about the MIMEDefang
mailing list