Re: More Matching questions - regexp

At 09:32 2000-09-27 -0500, tomcat(_at_)visi(_dot_)com wrote:
> strips off all header lines when replying (or replying and
> including the original message) except for (sic)
[snip]

except that it should gleefully *USE* the Reply-To header to override the 
address in the From:, for determining where the message should be 
sent.  This header should not be retained in the headers within the REPLY, 
but the sofware should take it into account.
Excepting that there's probably some braindead mailer out there someplace 
that won't support it right, you should be able to specify a Reply-To like so:
        Reply-To: originatoraddress(_at_)domain(_dot_)com, 
gatekeeper(_at_)bozo(_dot_)com

(the gatekeeper address will be cleartexted in the TO of the reply, which 
means they'll likely get copies of continued discussions if the originator 
uses REPLY-ALL -- but NOT if they just do REPLY)
If you did it this way, the webform perl script could set this header on 
the message going to the officer (possibly also setting From: to the 
originator address as well, if supported by the SMTP server settings), with 
a carbon copy going to the gatekeeper address (from the perl 
script).  Gatekeeper then sees the original message - doesn't DO anything 
with it other than logging it.
Officer receives the message, hits reply, at which time BOTH of the above 
addresses appear in their TO: line, and they compose and send their reply, 
copy goes _directly_ to originator, as well as to the gatekeeper, which 
again, receives a copy and does nothing more than logging it.
The webform perl script could hock a line into the top of the original sent 
body reminding the admin to not change the subject (or to at least keep the 
"reference code" (hash value) in the subject).
> I can't change any of these fields.  The Destination replies to the
> Gatekeeper
Why can't you change any of these fields?  Procmail (via formail) will 
gladly allow you to change them.
> To: Gatekeeper(_at_)bozo(_dot_)com
> From: clubofficer(_at_)bozo(_dot_)com
> Subject: Re: Webmail: The user's subject here *- bozo(_at_)bozo(_dot_)com
Looking at your problem, it REALLY seems like the perl script should just 
be setting a reply-to (if not a From: for that matter, but perhaps your 
server's SMTP relaying config won't allow that) and mailing the club 
officer(s), who, when they reply to the message, will end up sending a 
message to the reply-to address -- the web user.  If you need copies logged 
by the gatekeeper, do it as I suggested futher above.
An alternate way, if you must relay the message through the gatekeeper is 
to see if your ISP doesn't support plussed addresses, then mangle the relay 
address into the gatekeeper's address (you'll have some fun dealing with 
this).  Have you even considered just putting it within parens?
        From: <Gatekeeper(_at_)bozo(_dot_)com> 
(realuseraddress(_at_)wherever(_dot_)com)
        To: clubofficer(_at_)bozo(_dot_)com

Though some cheezeball email client will no doubt mangle the From (just 
replying with the address, and not the parenthetical text), so this may not 
be an appropriate solution.
Unfortunatley, some braindead corporate mail clients (Lotus notes comes to 
mind) mangle plussed addresses as well, because those clients don't obey 
RFC standards.  If your officers ARE NOT on such systems, you can probably 
ignore this concern.
> I want a copy of the original and of the reply in the Gatekeeper account,
> because I write the subjects to a log file, and can
> tell if the club officers have responded to the Originators
> email.  In the logfile I should see pairs:
What happens when the originator then sends a new message, this time 
directly to the club officer, now entirely bypassing the gateway?  Or do 
you plan to mask the officer's address (note: they may have it in their 
.sig!) to prevent future direct contacts, for which you'll be entirely out 
of the loop?
I can say from personal preference that if I have an _email_ address for 
someone, I'd rather use that than use some kludgy webform to make contact.
BTW - if your "webform" expects the user to have valid email, providing a 
mailto: instead of using a webform will increase your chances that the 
email address they use is valid (some people seem not to be able to relate 
their address properly, but usually their email client has it configured 
fine - and if not, they probaby won't get your messages anyway).
> I absolutely refuse to have folks email the club
> and not know if a response from the club got sent.  After
> 3 days or so, if the club officer did not respond, I respond
> or forward the original to someone else to respond to.
Okay, the logic finally comes out.  Would asking officers to voluntarily 
BCC the gatekeeper not work?  If they don't, then you can slap them around.

Yea, have the webform send it to your gateway, poss with a certain subject 
prefix (which confirms it came from the webform), which you strip, then 
forward the message to the appropriate officer:
Subject: [VISI-WEBFORM] real subject

:0
* ^Subject:[    ]*\[VISI-WEBFORM\][     ]*/\.*
{
        REALSUBJECT=$MATCH
}


> Finally, procmail deals with the reply by looking for "Re: Webmail:"
> (of course, I will make the first line in the body of the original
As indicated in a previous post of mine, you can't really expect that the 
reply WILL be prefixed with "Re:" - some mailers do things their own way:
        [Re:] Webmail
        RE2: webmail
        (etc)

The concept of having the webform insert some prefix into the message sent 
initially will catch the FIRST message, you strip that prefix off, and 
anything else that comes through you don't have to worry about being a 
webform or RE:reply, because the presence of the token would have 
identified the webform (though the From: of the webform system could have 
served that purpose, unless you change that).
You could also have the webform assign an incrementing number, or a hash 
(of the date/time/number) into the subject.
> Now, Originator and Destination can reply until hell freezes over,
> Gatekeeper is out of the loop.
So long as you're clear that this is what happens - AND that future 
contacts from the originator may go directly to an officer, without 
involving your system.
---
 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