[Mailman-Users] Limited posting
Amanda
arandall at auntminnie.com
Tue Oct 2 23:14:03 CEST 2001
Was ist VERP?
Like I said, I've moved away from Mailman for my announce-only
newsletter type lists, so it won't really help Mailman users to hear
this, but just in case anyone's interested.... With regards to bounce
numbers, we've developed a "pitchfork" approach (it has several prongs
with which to attack the problem).
One, the mail-send script keeps two logs: one that notes the address of
each message that was accepted for delivery by the local MTA, and one
that notes the address of each message that was not accepted, for any
reason (and in the case where there's an error code to log, it logs that
too). So we know which ones were rejected right out of the gate.
Two, if a message comes back to the originating *sender* address as an
RFC822 type bounce message (gods, but those are rare these days) or as a
message with some other regular expression that can reasonably be
identified as a notification that mail was not delivered for whatever
reason, the email address that appears in that message (top, bottom,
wherever) is saved to another file for digestion at a point in the
future. (Messages that don't fit these criteria and are not obviously
administrative requests get dumped elsewhere for a human to eyeball.)
Three, the file that contains those bounce addresses is masticated. If
an address appears more than once, the extras are discarded; then those
users are added to the master bounce file (if an entry does not exist
for that email address) or their count is incremented by 1 (if an entry
does exist). We can pretty much get away with discarding extras because
the mailings go out a minimum of forty-eight hours apart - the same time
frame set in our local qmail for returning a fatal delivery message.
This approach wouldn't be quite as clean on a list that has more
traffic. Anyway, that gives us the number of addresses to which mail was
apparently bounced. It also gives us the ability to export a list every
X days of email addresses which have bounced Y times (currently, about
every five weeks for users bounced 8 or more times), so that we can then
set a flag in the (full-fledged multi-purpose) user database that
basically makes that user's subscription inactive.
Is it 100% accurate? No; in fact I'm going bugnuts right now trying to
find the hoser who decided that a message from "nobody@"
whatever-dot-org with a blank subject that says "Sorry your message
couldn't be delivered. You probably have the wrong address."
(Literally.) without a forward of the original mail, an indication of
who the intended recipient was, nothing useful in the headers... Without
unsubscribing every single person at whatever-dot-org, I will probably
never find out which address is bad. Gerf - I hate a surprising number
of sysadmins out there... but anyway, I'd estimate we're reporting stats
that are in the 85-90% accurate range. That's good enough to track
trends and make the marketing weenies happy.
One note about the suggestion of using a marketing-tracking approach of
putting an image in your mail that lives on the website ... this will
definitely skew your stats because of the significant number of people
who don't have HTML-enabled mail clients. We actually run two lists for
the newsletter - a text-based and an html-based - to accomodate, for
example: older AOL clients, AOL users who have set preferences to block
mail with embedded images, a significant number of people using Novell
GroupWise (as the admin doesn't have to allow the components that
provide a means of reading HTML-based mail, and frequently doesn't even
know it can be done), older versions of Eudora, Claris, and other
lightweight clients which are very common with hospitals and schools,
and apparently some people who installed some funky "security patch"
(ha) to Outlook (OE? I forget which).
Nothing is as easy as it used to be...
=)
Amanda
J C Lawrence wrote:
> On Tue, 02 Oct 2001 12:08:51 -0700
> arandall <Amanda> wrote:
> > Jim Kutter wrote:
>
> >> That brings me to another question - what's an accurate method of
> >> counting the number of bounces? I was grepping the bounce log and
> >> counting the number of bounces for my newsletter. That will only
> >> work however if I wipe the bounce log every few days - and even
> >> then I won't get a very accurate count... Also - as far as stats
> >> go, in the smtp log, is that a fair count for how many messages
> >> really got sent?
>
> > Hmm. This (the bounce-counting) is one of the reasons I ended up
> > ripping Mailman into many component pieces and then ended up
> > custom-writing something completely different for the newsletters
> > themselves. If you find a clean and accurate way to do that using
> > Mailman, let me know. :-)
>
> Without using VERP its actually impossible.
>
> -- Mailman attempts to determine subscriber address by parsing the
> bounce. This is cheaper than VERP, but is also error prone.
>
> -- There is not a 1:1 mapping between bounce messages and sent
> messages. A single send message may generate multiple bounce
> messages from intermediate MTA's if they are unable to deliver it
> quickly. Further, given a history of sending mail, you may
> receive multiple bounce messages all from previous mailings (prior
> to your last) with no way to reliably distinguish them from
> bounces in response to your current mailing.
>
> Bounce counting under Mailman does give numbers, but they are
> unreliable and shouldn't be used for anything other than SWAGs. To
> get "real" bounce counts you'd not only have to use VERP across your
> subscriber base, but also VERP across your mailings so that every
> message you send not only has a unique return address for each
> subscriber, but also has a unique and trackable return address for
> each message sent to each subscriber.
>
> This is doable, but is not entirely trivial. Its quite outside of
> Mailman's base area of interest.
>
> --
> J C Lawrence
> ---------(*) Satan, oscillate my metallic sonatas.
> claw at kanga.nu He lived as a devil, eh?
> http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live.
More information about the Mailman-Users
mailing list