Hi,
Wow, this is getting complicated, but it's OK, I want to learn
all of this stuff.
On Wed, 5 Feb 1997, David W. Tamkin wrote:
The problem, Ken, was that what you really needed was the number of
addressees, so we were trying to count only the names in such lines.
We didn't want to include the @-signs in places like Message-Id:, From:,
or Return-Path:. Now you have a new approach: you'll allow fifteen
@-signs to allow for those in other headers and a reasonable number of
addresseees.
This is a stop-gap measure. Ideally, I'd like to add up the @'s (or commas,
I don't care) within the To: and Cc: lines only. That, and other conditions
that I know how to do.
I've been stripping down the rules to the minimum. Once I figure out
how to make procmail do what the manual says it can do (I'm almost there)
I'll put them back together again.
Me:
| That still leaves a problem with the internal Egrep, and that's counting
| commas or '@'s in ONE FIELD. (Actually two fields, To: and Cc:) To do
| that, I'll still have to resort to an external program like countat. One
| might extract a field using formail first, but that still means
| launching another external prog!
Well, we can do it with formail, though, and you won't need the disk space
for countat.
I wasn't aware that formail could count. I could let have it seperate
out fields and then count the fields with another program...?
There's still exec overhead...
...
And that is why we have been answering!
I do appreciate it, it's the man pages I'm frustrated with, not this
list! Thanks again.
| Is there anywhere in the manual pages that I was supposed to divine
| this syntax? I'll admit guilt if it's in there somewhere...
The procmailsc manual shows the weight of a condition and the condition
itself on the same line in all examples. I do not know where you came
up with the idea of separating them.
I can't find where a condition is actually an external program, except
in the case of "?".
| > By the way, "h" is meaningless on a recipe whose action line is to launch
| > a brace nest. If you want any or all recipes inside the braces to act
only
| > on the head, they need their own h's: flags are not inherited.
|
| The procmailrc man page says that the "H" flag means to egrep only
| the header. Since I didn't want the rule acting on the body, and
| I had started with the internal egrep, I had the H flag. The body
| might have a bunch of @'s in it that I don't want to count.
Stop. I said "h". You're saying "H". They are two entirely different
animals.
I was wondering about this, which is why I capitalized it like the man
page did.
"h" means "pipe, save, or filter only the body." It is meaningless if
the action line is a left brace. The default is "hb".
Question, does that mean "pipe, save, or filter only the body" for
the conditions, or the action taken? I think it means for the action.
"H" means "unless overridden for a specific condition, the search area is
only the head." "H" is the default; you must specify "HB" or "BH" to
search both head and body. If you had an "H" on that recipe it would have
been unnecessary (because "H" is the default) but it would not have been
*wrong*. "h" on a recipe for launching a brace nest is harmless, but be-
cause it shows confusion about what the flags do and where they belong, it
is wrong. (For example, you might think it feeds only the head to all the
recipes inside the braces.)
Hm. I was only trying to restrict the search area, and I'm doing just fine
on showing confusion, thank you. :)
| > Now, if you really want to count all @-signs in the head and allow for
| > fifteen legit ones (From:, Message-Id:, a few Received:), here's how
| > you code it without outside programs:
| >
| > :0c # Are you sure you want a clone here?
| > * 1^1 @
| > * -15^0
| > {
| > whatever you had in the braces
| > }
|
| Wow, so achingly simple... :) Of course, I had to go and write C code...
|
| But wait, it still doesn't allow me to count @'s (or commas) within one
| particular header line.
Right. I'll get back to that at the bottom.
...(more stuff about H and h snipped, I understand what that's about now).
Now, there are two other problems with counting @-signs: (1) they will over-
look local addresses if the message originated on your site and
This is actually OK. It's good to recognize the possibility, though.
(2) even
in To: and Cc: headers, they might appear in the comments on addresses (where
the real name belongs, but where people often put other things).
Point noted. I would have enough headroom in the count to compromise. (15
and 20 are just working numbers until, well, I get something working).
So here's my suggestion, and sorry that it runs a program, but it's the best
I can think of.
No problem, if there are 5 ways to solve a problem, I like to know all
of them.
(Unfortunately extraction into $MATCH will not get multiple
headers with the same field name; we can get the first or the last that way
but not both nor any in betweeen.)
Oops. Possible big problem. Spam and such are not known for their
RFC-822 compliance. I guess if I set it up for whatever sendmail
does (first occurance, I think, not sure) it'll work OK.
We see whether there are Resent- headers,
and if so, save them in a variable; otherwise we save regular addressee
headers there:
:0h # H is implicit; this is h
* ^Resent-(To|Cc):
TARGETS=`formail -czxResent-To: -xResent-Cc:`
:0Eh
TARGETS=`formail -czxTo: -xCc: -xApparently-To:`
Note that we used formail's -c option to get single lines from continued
headers.
Aha! That's cool.
Now, the number of addressees should be the number of non-empty
lines (procmail always sees an extra empty line at the end of a search area)
plus the number of commas:
:0
* 1^1 TARGETS ?? ^.+$
* 1^1 TARGETS ?? ,
{ ARROWS = $= }
This will still overcount if someone has a comma inside a name comment.
That would be acceptable.
Thanks,
Ken.
-------------------------------------------------------------------------
Mail: kmarsh(_at_)charm(_dot_)net | Edit a binary .INI file, then
tell
WWW: http://www.charm.net/~kmarsh | me that UNIX is too complicated.
-------------------------------------------------------------------------