At 11:10 PM -0400 7/30/02, Gyan Penrose-Kafka is rumored to have typed:
> I looked at the log and I kept seeing: "formail: Duplicate key found: ..."
That implies your message is returning to the mailing list for a second
go-round. Sounds (on a guess, based on insufficient information) that the
address you subscribed is somehow externally being redirected back to the
list address. This would imply a problem outside SmartList, maybe in your
.procmailrc file.
Simple way to see if the message was "delivered" my SmartList is to check
for its existance in the listdir/archive/latest directory (assuming it isn't
a digested list, of course, although it'll be there in the digest.body file
if it is).
You're on a hosting service; is it fair to assume you are using a
.procmailrc file to direct mail to the list on a virtual account? Or are you
using some "control panel" supplied by your provider to direct the mail?
(This is a seperate thing from a control panel that _controls_
SmartList...I'm trying to get a handle on how you're getting the mail
delivered to the list, since your previous posts imply you aren't rooting the
box and so need to use some other method than the alias file.)
Ah...crap.
I'm almost certain I know _exactly_ why you're getting this problem, and
it's partially my fault. Nothing like spending a minute or two to go back
over the last month's postings and catch up on the thread, which I should
have done before I started typing.
A while back, I explained that you could use a .procmailrc file to direct
mail to your list on a virtual domain, like:
:0
* ^TOlistname(a)yourdomain.tld
|/full/path/to/SmartList/.bin/flist testing
...and that's absolutely correct. But let's use the hypothetical domain
mydomain.tld and the hypothetical list mylist and examine what's happening.
You have:
:0
* ^TO mylist(a)mydomain.tld
|/full/path/to/SmartList/.bin/flist mylist
...in your .procmnailrc file. Ok, so far, so good. Now I subscribe as
charlie(a)lofcom.com. I post, SmartLIst accepts the mail, and sends it off to
subscribers, including me. Cool.
Now you subscribe the address gyan(a)mydomain.tld to the list, and send a
message (or _I_ send a message, doesn't matter). The message comes in, is
seen to be to the list address, and is piped to flist. SmartList distributes
it to the subscribers, including gyan(a)mydomain.tld; that copy of the
distribution comes into your .procmailrc file, is seen to be to the LIST
ADDRESS, and is piped to flist...which recognizes that it's a duplicate.
Blame the fact that it's been a whole lot of years since I had to run
SmartList as a virtual user on a shared machine, and not anticipating that
you'd not realize subscribing an address on the same account was a Bad Idea.
If you're going to subscribe an email address on the same virtual domain (or
a parked domain that uses the same real unix account, for that matter),
you'll need to trap out for that condition using something like:
:0:
* ^X-Loop:.*mylist@mydomain.tld
* ^TO mylist(a)mydomain.tld
/full/path/to/system/mailbox
:0
* ^TO mylist(a)mydomain.tld
|/full/path/to/SmartList/.bin/flist mylist
What you _should_ do is subscribe an external address to the mailing list;
if you have an account somewhere else, like maybe your access provider
(cox.net?), use it instead of an address on the same virtual server - that
will eliminate the problem entirely without having to trap out the mail
coming to you (different server, no harm no foul). You could also use other
header fields in the trap recipe (X-Envelope-To: if your provider adds it, or
maybe a Received:.*unixusername, or something else), anything that will ONLY
occur in mail to you, not to the list. Finally, instead of subscribing
yourself, you could add as the last recipe in the rc.local.s20 file:
:0 c
/full/path/to/system/mailbox
Note this problem will happen on _any_ address delivered to the same unix
account, and so running the same .procmailrc file. This also likely accounts
for the repeting subscribe.txt file loop...I'd almost bet there were
X-Diagnostic: headers in those things (ALWAYS check messages from the
-request side for X-Diagnostic: header fields...they are your friends).
You're also going to have to anticipate -request mails as well, especially if
you use an account on mydomain.tld as the admin account for X-Commands and
the like. I wouldn't; I'd use an address on an external machine to avoid all
the possible pitfalls.
If you don't understand what I'm saying here, let me know and I'll try to
explain it better; it's a simple problem, with a simple solution, regardless
of my verbosity.
Charlie (who should have figured this out long before now)
