At 16:28 2000-12-12 -0700, Jim McMaster wrote:
Point of contention: you did not change your mail DOMAIN. You changed
your mail HOST. There's a BIG difference.
The procmail list address changed about six months ago. Please make a note
of the current address.
1) Some idiot mail lists have broken unsub processes, and will not unsub me
no matter what I do.
Sounds like you need to forge an unsub for yourself - a process made easier
by the fact that you're still supposed to receive messages destined for the
old account (in the event that there is a confirmation requirement).
Examine the received headers for indications of what actual address is
subscribed (the envelope address at your old account). This may differ
ever so slightly from the regular address you used.
2) My current setup bypasses my spam filters.
If as you say later in your message, you're not seeing any log activity,
and test messages appear to go to the ether, how is it that you know this,
when apparently no messages are being received?
3) Manually telling people about the new address is a pain.
Deal with the mailing lists issue. THEN, either set up an autoreply to
everyone who mails you at the old address (since, after all, you shouldn't
be getting any messages at it anymore), or write a recipe that gets the
reply-to info for each message that comes through and emits it to a
file. On some interval, you can look at the file, run unique on it, and
use it to send form messages to the people who insist on continuing to send
messages to the old address.
Eventually, if you've _really_ changed addresses, what you do is CLOSE the
old account (or set it up to bounce all incoming messages). If someone
can't be bothered to note your new address when you tell them, there's no
reason you should bother to process their email.
Presumably the "new" .procmailrc is running on the old host. You don't
actually make this clear, certainly not from the top of your message - I
infer it from your mention of the .forward
#Tell people address has changed
cluetime: your autoreply recipe sets an X-Loop, BUT DOES NOT CHECK FOR
ONE. Thus, you may think you're avoiding a loop condition, but you are not.
"The email you just sent has been automatically forwarded.\n" \
clue #2: as long as people believe their email is being forwarded, they
will be less likely to take prompt action to recognize your proper
address. You're better off telling them that the message WAS NOT forwarded.
I set up the .forward as:
"|IFS=' '&&p=/apps/bin/procmail&&test -f $p&&exec $p -f-||exit 75#mcmaster"
Have you verified that procmail is actually /apps/bin on the mail
host? This isn't a typical location for it.
Have you attempted to pipe a message into procmail on the old host?
Is your .foward _world readable_ ?
Have you tried the more abbreviated form of the .forward:
"|IFS=' '&&exec /apps/bin/procmail -f-||exit 75#mcmaster"
Does this work?
When I send a test message to the old address, it just vanishes.
Q: what about the _other_ messages presumably appearing there? Are they
dissappearing too? if not, I'd suspect that your ISP has a mail config
snafu, and your message is being ditched on its way between the two
similarly named accounts.
There is no log file at all, and the mail does not appear in any of the
usual locations. It looks like procmail is not running at all. Can
anyone tell me where to start looking for the dumb mistake I am making?
Are you sure it's being forwarded? Try renaming your current .forward and
replacing it with a simple .forward containing nothing more than your new
address and send a test message. Do you get that?
If there's no log activity, then it would seem as if it isn't being
processed AT ALL.
You might find that using _fetchmail_ to retrieve messages waiting at the
old account (if they're available via POP3 or IMAP, or a few other
protocols) and performing all your procmail scripting from the new host may
solve your problem. Have you tried issuing POP3 commands against the old
account (telnet oldhost 110 ; USER username ; PASS password ; LIST ;
QUIT)? Perhaps the messages are being deposited directly into a POP mailbox.
---
Please DO NOT carbon me on list replies. I'll get my copy from the list.
Sean B. Straw / Professional Software Engineering
Post Box 2395 / San Rafael, CA 94912-2395
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail