[Mimedefang] common practice

[David F. Skoll]

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.