Sandy, I agree. However, the reporting company is looking for raw server logs. I can give them as many real-world numbers as I want (which I have), but they want what they want. The problem is, that I don't think the people who are asking for them, really know what they are asking for. They are just doing what they are told. My mailing lists are usually pretty clean, as I use a special mailbox to receive the bounced mail and then have a 3rd party utility called Boogie Bounce (awful name, great product) that can scan the bounced messages and determine if it is a soft or hard bounce. If if is a hard bounce, I remove the email from my list. The reporting company does not care about this though and only wants SMTP logs.
Thanks, Dean On Tue, Aug 26, 2008 at 1:19 PM, Sanford Whiteman <[EMAIL PROTECTED]> wrote: >> There are many virus scanners and smtp relays, etc that do not >> reject the messages and the user's email will later bounce. > > I would take this a giant step further. When it comes to bulk mail, > unless you are certain that you've been whitelisted with all of your > subscribers, a proportion of messages will get devnulled or dumped > into a rarely-checked spam quarantine. As Kevin rightly notes, you > have still made a good-faith effort to hand off delivery to the > persons responsible for the remote domain. But in reality, you must > subtract a consistent % from your apparent # of "true" recipients. > > This brings me to another point, though. If the reporting agency is > content with knowing how many subscribers' MXs accepted each message, > why don't you just count zero-hop _bounces_ and subtract them from the > total? Don't bother with extended log parsing. Just check the SMTP > sender's mailbox after the queue lifetime of the message has expired. > How does not get you just as "true" a number as inspecting the logs? > In fact, it'll be *more* "true" unless in your parsing logic you are > sure to not count transient failures, but only the final disposition > known to IMail. > > Generally, I find that this kind of auditing is much better done using > after-the-fact parsing of the bounce mailbox in combination with the > original recipient list. You can do a lot more fancy parsing on what > is sure to be a smaller set of data (such as separating by bounce > type, number of bounces in a row for a given user, etc.). > > --Sandy > > > ------------------------------------ > Sanford Whiteman, Chief Technologist > Broadleaf Systems, a division of > Cypress Integrated Systems, Inc. > e-mail: [EMAIL PROTECTED] > > SpamAssassin plugs into Declude! > http://www.imprimia.com/products/software/freeutils/SPAMC32/download/release/ > > Defuse Dictionary Attacks: Turn Exchange or IMail mailboxes into IMail > Aliases! > > http://www.imprimia.com/products/software/freeutils/exchange2aliases/download/release/ > > http://www.imprimia.com/products/software/freeutils/ldap2aliases/download/release/ > > > To Unsubscribe: http://imailserver.com/support/discussion_list/ > List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ > Knowledge Base/FAQ: http://imailserver.com/support/kb.html > -- __________________________________________ Dean Lawrence, CIO/Partner Internet Data Technology 888.GET.IDT1 ext. 701 * fax: 888.438.4381 http://www.idatatech.com/ Corporate Internet Development and Marketing Specialists To Unsubscribe: http://imailserver.com/support/discussion_list/ List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://imailserver.com/support/kb.html
