{[ reply-to is now directed to me, _not_ the list, since this is _way_
off-topic now, but Lonnie you won't be able to successfully send me
e-mail direct from Hotmail -- I don't ever accept mail direct from
hotmail.com, sorry. ]]
[ On Sunday, June 13, 2004 at 17:51:43 (+0000), Lonnie Santella wrote: ]
> Subject: Re: [Exim] SMTP Logging
>
> Any help would be greatly appreciated. Thanks.
I really do think you need the professional services of a good
information systems analyst first.
This is just a wild and crazy guess that's no-doubt wrong but it sounds
like you've got a bunch of junior SQL/VisualBASIC "programmers" (I
hesitate to describe SQL hacks as "programmer", let alone VB hacks :-)
who're making up some half-baked and never-integrated design as they go
along and they're basing their work entirely on the very fuzzy requests
made by your business. That might be effective enough for the short
term but it's hardly a good base for a long-term business strategy.
Feeding mail into a program is extremely trivial (hint: aliases) however
feeding mail into a database, especially a relational database, is
literally _impossible_ if you don't know the schema and functional
requirements for that database long before you write a single line of
code in any language.
Note that you've already described two very separate and different
problems too.
The first problem of sorting out which addresses are valid and which are
not based on DSNs returned from a campaign could easily be handled by
using a proper mailing list management package, one integrated with your
address database. I have a colleague who modified Mailman to do just
this very sort of thing for one of his clients. Other techniques such
as VERP could help with this too.
The second problem could probably be pre-empted somewhat and reduced in
scope a _great_ deal by arranging to have separate reply addresses for
each campaign and then routing those different incoming addresses to
separate locations. This would allow you to use a "database" such as
Cyrus IMAP to store the replies, search through the replies, and so on.
Perhaps you could even use automated seive "filters" to initially
categorize them into sub-folders too ("yes please!", "what the heck is
this about", "more info!", "stop bugging me", etc.).
A really good file store _is_ a really good database for many
applications, and with the help of a system like Cyrus IMAP that's
already designed to index, sort, and manage _very_ _LARGE_ amounts of
e-mail (hundreds of millions of messages and more can _easily_ be
handled by it in a _very_ efficient and scalable manner) then you'd have
a very flexible and "future-proof" system to allow all kinds of
possibilities on the searching & reporting side, not to mention but that
your users can also still treat it exactly as the e-mail it really is.
(And of course IMAP already provides you with a platform agnostic
client/server protocol specifically designed for accessing mail in a
highly efficient and effective and flexible way that you could then use
to interact with your e-mail database -- and search functionality is
built into it.)
However these are still just random thoughts based on your still fairly
vague description of your functional requirements, though given my
experience with what I believe to be similar situations I can now
extrapolate much of what I'd need to know to really understand your
problems deeply enough to guess that I've now given you more than enough
of a nudge in the right direction. :-)
Now if I tell you any more I'll have to send you a bill! ;-)
--
Greg A. Woods
+1 416 218-0098 VE3TCP RoboHack <woods@???>
Planix, Inc. <woods@???> Secrets of the Weird <woods@???>
