procmail
[Top] [All Lists]

Re: Undesirable characters in subject text

2003-05-27 16:11:30
On Tue, 27 May 2003 14:06:38 -0700, PSE-L(_at_)mail(_dot_)professional(_dot_)org
(Professional Software Engineering) wrote:
=> I'm guessing that you didn't try the third invocation, as suggested (or 
=> that you didn't run ANY of them).  It's a learning exercise, and most 
=> people learn by doing.  Please actually try the shell invocations and see 
=> what they do, and you might gain a better understanding of them.

        Actually I did, thanks. I really do thoroughly read and
try to understand most of your posts here, Sean. Despite your
gruff nature (which is often amusing, at least when it's aimed at
someone else), I've learned a lot from you here in the list. As I
written here before: Thank you.

=> You may want to use:
=> | echo -n "$SUBJECT" >> somefile
=> Which would omit the trailing newline which echo would otherwise tack onto 
=> the emitted text.

        It's only the "odd" ones that I wanted to suppress, the
ones that are the result of the unescaped wildcards.
 
=> You're going to have a difficult time filtering out characters that may 
=> appear in multiple locations within the string - a simple match operator 
=> would allow you to bracket the text, but that's likely to produce an 
=> undesireable result more often than not whenever there is a symbol you wish 
=> to omit.  You could probably do it with a recursive INCLUDERC procmail 
=> recipe, but the overhead could (not to mention the complexity) end up being 
=> a lot more than simply invoking a program such as sed or tr, which are much 
=> better suited to such a task.

        Guess I'm back to square one.  I don't know sed and I'm
not sure I want to incur the costs of the call. Also if I must,
I'd rather be lazy and try a cook-book sed example given by
another than try to stretch my brain around more *nix stuff.
I've written code commercially since 1969 but I was never a *nix
geek, sorry (though I must admit to enjoying the perverse and
arcane nature of procmail).

        I'll just use a few broad character classes to allow all
the "standard" characters and let it effectively truncate where
it finds the first wildcard etc in that field.  The subject is
only carried along for info so it's not that important.  I am
getting what I want, which is the sending IP#, the reverse
lookup, and any HELO string given during the envelope delivery
along with To/From/Type/Return-Path etc.  It's all very
imformative.

        Your suggestion way back when, to extract everything into
vairables first and then only work with the variables has served
me well.
 
=> I'm wondering how you're ensuring that components from simultanious 
=> messages don't interleave in your dbase file, or is the only field the 
=> subject?

        The record is assembled from several other variables just
before it is written|echoed (same for the log details) and the
dbase record is done just before the log details are generated
which is just before the actually delivery to file or address.
All of it is "subroutine-ized" with INCLUDERC and variable usage.
I used to have problems with interleaved logs but not much lately
as it all goes at one time.

        BTW: I'm currently writing approx 4k records a day and
all seems to be working fine. I'm just about to turn on the
actual database link soon.

=> keep in mind that "echo" itself is a program you must invoke 
=> - so writing your own helper would take its place, meaning you'd have 
=> little difference in effective overhead,

        Ah, thanks, that makes sense. I was looking for the
quickest and least stressful "handoff" but I guess I can probably
find someone to write me a little helper for that.

        Of course, the easiest solution might be to make the
program which periodically reads the file and writes it to the
MySQL database a bit more intellegent when it comes to handling
each line - as long as the wildcard problem is limited to an
extraneous embedded linefeed.

        Thanks,

        - Don

_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail