On 07:01 AM 4/28/01, Amy Stinson wrote:
>On 27 Apr 2001, at 22:19, Alan Clegg wrote:
>> Several people responded to my recent query regarding dealing with AOL.
>I'm not sure what you mean by high volume. I have probably 500 AOL
>subscribers and they get 25-100 emails from my site a day (excluding
>digests). I've had no problems.
I'm on a mailing list for the Mailman list server software. The discussion
quoted below was seen on that list a few days ago.
As I understand it (and I'm not an email expert, so someone please correct
me if I understand wrong!), it means that depending on your mailing list
software settings and on your mail server software settings, your message
envelope settings can either send more messages to fewer addresses at a
time, or fewer messages to more addresses at a time. And if you send to
more than 17 addresses at a time, list email sent to AOL can get silently
dropped due to filtering AOL has that looks at the number of recipients in
the message envelope.
It appears (and Alan might be able to confirm, if he's made the changes
noted below and had good results) that if you discover that your list's
posts are being silently dropped by AOL, you can avoid the contract they
want you to sign by changing your mail server and mailing list software
settings to avoid triggering their filters. Alternately, you can sign (and
abide by) their contract and then presumably get whitelisted by their
anti-spam filters.
It would seem that geeks would prefer the former solution, and marketing
types with their "opt-in announcement lists" would just opt for the
later. Most geeks (myself included) usually think that having a contract
with AOL for the purpose of getting AOL to accept our list email is
tantamount to a deal with the devil. OTOH, most marketing types (and I
work in marketing, so I know the type pretty well :-) would tend to think
that they could *brag* about how they have a special deal/contract with AOL
to ensure delivery of their list to AOL subscribers, as if they have scored
some big deal. Heck, I wouldn't be surprised to see if some of these
"opt-in announcement list" marketing firms issue a press release to
announce their special AOL mail delivery contract!
jc
<quote>
>>> > Is there a way to bump this down to say.. 2 people per
>>> envelope? Vs.. The > 20 or 30 it seems to put in now?
>>>
>>> Sorry to waste your bandwidth, I found what I was looking for in
>>> the Defaults.py .. Default was 500, I bumped it down to 2.. What
>>> do you know, sending messages to 25000 people at a time now, goes
>>> quite fast.
>
>> Increasing this number should result in lower bandwidth usage and
>> higher performance.
>
>This is not necessarily true, and depends heavily on the total
>number of spool entries and the level of contention among queue
>runners for deliveries as it reduces the total level of parallelism
>possible in the delivery process. It also depends on the average
>load on your mail spool. If your spool is constantly busy then lock
>contention will be consequently lower as the spool never drains and
>there are always other entries to process.
>
>Consider the simple case for your 1K count envelope. The gain is
>that due to the low number of transactions the handoff to the MTA is
>rapid. The problem is that without a constantly active mail server,
>the delivery rate by the MTA will tend to be low.
>
> For a list with 25K members there are now 25 spool entries. This
> means that there can be at most 25 queue runners. Problem is,
> some number of those queue runners are going to be locked at any
> given instant dealing with slow/unresponsive MXes, leaving your
> total "live" count of actively delivering queue runners as a much
> smaller (and rapidly decreasing as the situation becomes more
> pessimal across the queue lifetime).
>
> Conversely, setting the max envelope size to a small value, say
> 10, will result in 2.5K queued entries for the same list post.
> Given an MTA configured for say 50 queue runners (depending on
> system I typically run between 20 - 80 with a max of 10 per target
> MX) you'll likely find that you can maintain queue runner
> saturation across the majority of the queue run time (depends on
> the distribution of your targets). Less contention over queue
> entries equals greater parallelism equals faster delivery times.
>
>ObExample: With a 2K member list with envelope seize set to 500 on
>my main test system under Postfix it takes roughly 14 minutes to
>drain the queue of responsive MXes. After reducing the envelope
>size of 5, the drain time is now just over 3 minutes before the
>spool becomes quiescant (only slow MXes left). Tha gating factor on
>that 3 minutes is transactional overhead on the deliveries, not disk
>IO or bandwidth.
>
>Further, values above ~20 will tend to result in your mail being
>silently dropped/deleted by AOL. Its not clear what the exact
>trigger value is for AOL, and of course they don't publish it, but
>empirical testing suggests that it is currently 17.
</quote>
