Sorry if I asked my question in a confusing way. I am not a mail expert. I
used procmail on that account for years, and am successfully using it on the
new account. Now I am trying to set procmail up again on the old account. I
know I am doing something wrong, but cannot figure out what it is.
In message
<5(_dot_)0(_dot_)0(_dot_)25(_dot_)2(_dot_)20001212161350(_dot_)06977eb0(_at_)mail(_dot_)professional(_dot_)org>,
Professi
onal Software Engineering said:
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.
Sorry for not knowing the difference. The mail servers falcon and sweng are
in separate NIS domains with different admin groups.
The procmail list address changed about six months ago. Please make a note
of the current address.
Sorry again. I grabbed the address from the last message I saved in my
procmail folder, apparently before the list changed.
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).
I have followed the directions involving sending mail to coded addresses with
no results, and have checked the specific email address subscribed. I also
have sent personal emails to the list owners, who do not respond. I think
these guys ad rates are based on subscription numbers, and they have no
interest in unsubbing people. I am treating them as spammers at this point.
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.
Did that, actually. The address matches what I expect.
2) My current setup bypasses my spam filters.
I meant the setup on my new account receiving the forwarded mail. My spam
filters are after I pre-sort mailing lists. I break out the forwarded stuff
before mailing lists so I see those in the "old address" as well.
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?
When I just place my new address in the old account's .forward, mail from
mcmaster(_at_)falcon(_dot_)stortek(_dot_)com to
mcmaster(_at_)sweng(_dot_)stortek(_dot_)com appears in my "old
address" folder as I expect. When I try to invoke procmail, an identical
message just vanishes, and no /home/mcmaster/Mail/log file appears on the old
account. The message dose not appear in the Mail directory (mh folder) or
/var/mail/mcmaster (mail spool) on either account, nor do I get a bounce
message from sweng.
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.
Probably the best solution. I do not have authority to close the old
account, as I am not a sysadmin. It is not that people are ignoring my
requests, it is just that a lot of people have the old address, some of whom
write very infrequently. The volume of manual replies is what I would like
to avoid.
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
Yes...sorry for the confusion.
#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.
Oops! I will fix that. (If I can get this to work at all)
"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.
As I said, people are not ignoring requests, there are just a lot of them.
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.
I did verify the location of all executables. This is where the EDS
contractors for sweng put all their installed software...idiots.
Have you attempted to pipe a message into procmail on the old host?
Is your .foward _world readable_ ?
Yes
Have you tried the more abbreviated form of the .forward:
"|IFS=' '&&exec /apps/bin/procmail -f-||exit 75#mcmaster"
No, I just copied this from the man pages when I started using procmail years
ago, and have always regarded it as "black magic."
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.
For testing, I do a quick set of "mv" commands to swap .forward files, send a
test message, then rename the files back. I really can't tell if other
messages appear during that span, but the volume is in tens per day so odds
are against it.
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?
That has been my setup since July, with the problems I am trying to solve by
setting procmail up on that account again. I know I am being stupid, but
cannot find the problem.
If there's no log activity, then it would seem as if it isn't being
processed AT ALL.
Exactly what I suspect. Now I just have to figure out why.
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.
We do not run POP here. I do not know about IMAP. "fetchmail" does not
exist either. The mail host in the sweng domain (swmail) refuses telnet
connections.
Thank you for your patience with the clueless. I am sending this to the new
mailing list address. Help? Anyone?
Sean B. Straw / Professional Software Engineering
--
Jim McMaster
mailto:mcmaster(_at_)falcon(_dot_)stortek(_dot_)com
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail