On Fri, 16 Jun 2000, Ross Boylan wrote:
> Duplicate messages are a chronic nuisance for me. Their causes are varied,
> but I would like to get rid of them. I gather this is considered a job for
> procmail. I have various reasons for not wanting to use procmail (see
> below), but it seems it should be easy to do in exim.
Well, I personally would find it hard to define exactly what a duplicate
message is. For example, I often get "duplicates" via the mailing list,
but the version that comes from the list has a bit stuck on the end -
sure, I could craft hand code for one particular list, but in general...
> As an added wrinkle, I want mail to my wife to be duplicated to me, so I
> can tell her when she's got mail. I'm doing this now with a smartuser
> director.
Many ways to do that; aliasing, forward file, unseen director ...
> After the smartuser director just mentioned has split the message,
> Put a duplicate_kill director.
> This has a condition, which is an embedded perl script.
> The perl script manages a database of seen message keys (keys of the
> message id in the header seem to eliminate a lot of the duplicates for me).
> If this message has seen before, it returns true.
> Otherwise, it writes the key into the database, and returns false. (this
> is the part I can't do without perl, as far as I can tell. Exim's lookup
> facilities let me check if the key exists, but do not let me write one out).
> Back in the duplicate_kill director....
> if the condition is true (the message is a duplicate) it uses an
> appendfile transport to stuff the message in a duplicates file (just in case).
> Otherwise, processing proceeds as normal.
That may work, assuming you can identify duplicates (as mentioned
above). Presumably the database is a per-user database.
Actually, you don't need a special director. Just put the whole thing in
the expanded string which determines which mailbox the message is
delivered to: normal, or potential duplicate.
> 3. I have already invested time learning exim and getting its filters just
> so. If I use the filters (local ones), I'm not using procmail, and
> vice-versa (I think).
You can use both Exim filters and procmail if you really want to.
> 4. If I use procmail, or any other pipe, and try to send the results back
> to exim I have to worry about setting up a special port, making sure I'm
> conforming to Debian's and exim's requirements, and worry about special
> tricks to prevent loops.
Procmail can't send "results" back to Exim - only a return code - or do
you mean it wants to resubmit a message? That's getting hairy.
> 5. It just seems ridiculous to have something described as a MTA which
> neither gets nor sends most of the mail (since fetchmail and procmail do
> the work).
I didn't write Exim for your environment!
> Speaking of documentation: It wasn't clear to me what addressing
> information different macros would pull out.
Not sure what you mean by "different macros".
> I tried it and think I figured out what was going on (namely that
> intermediates didn't count). For example, I thought maybe mindspring (my
> ISP) would show up as the sender of everything, since it was the
> immediately preceding system in the delivery chain. But it would have been
> nice to have more of an explanation.
You need a general "Internet Mail" explanation; this is not
Exim-specific.
> Also, the manual is very nice as a reference, but is not so helpful for
> getting started. It provides little guidance for what is essential or
> important vs peripheral. Now maybe you shouldn't use exim unless you know
> what you're doing, but I think I'm not the only one using it as I do
> (namely a home system for which I want to use mail, not become a mail
> guru). It would be nice to have something like a user's guide.
This is a FMC (Frequently Made Comment).
The manual *is* a reference manual. Exim was written for use on more
serious servers than single-user home systems; I was kind of expecting
it to be run by sysadmins with mail responsibility, who knew the basics.
Now, it's really nice that it has found favour in so many different
environments (single-user to really big ISPs), but unfortunately, I am a
mere mortal whose days are no longer than anyone else's, and I do happen
to have a life outside computing as well. I just have not had time to
maintain anything other than the reference manual as well as keep up
with the continuous demands for updating the code (over 5 years now, and
not slowing down). I did eventually put up an FAQ, which has helped
reduce the volume of some of the questions.
The possibly Good News is that I am trying to write a book about Exim,
and it is supposed to contain some more introductory material, as well
as a general introduction to Internet Mail. The Bad News is that it is
nowhere near finished yet. (I have also run a couple of one-day courses,
but of course only some people can get to those.)
As I have said many times, if anybody else wants to write an
Introductory User Guide to Exim I will be only to pleased to support
her in whatever way I can. In many ways, I am not really the right
person to write basic introductory stuff, because I am too deeply
involved.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
