Timothy Luoma | 1 Apr 02:03 2001
Picon

matching when two lines match


I have this and it works well:

	:0B
	* $ ^Wrote file \/.*
	{ ATTACHMENT=$MATCH }

But if there is more than one occurence of ^Wrote file in the email, it
still only matches 1 :-(

How can I $MATCH all of the occurences, especially when I have no idea how
many there might be ?

Thanks
TjL
David W. Tamkin | 1 Apr 06:41 2001
Picon

Re: matching when two lines match

Timothy asked,

| I have this and it works well:
| 
| 
| 	:0B
| 	* $ ^Wrote file \/.*
| 	{ ATTACHMENT=$MATCH }

You don't need the "$" modifier there.

| But if there is more than one occurence of ^Wrote file in the email, it
| still only matches 1 :-(
| 
| How can I $MATCH all of the occurences, especially when I have no idea how
| many there might be ?

What exactly do you mean?  You can't extract scattered selections from the
message into $MATCH.  I'm guessing that you want the rest of every line that
begins "Wrote file " (and doesn't end there) in the variable, and that's not
going to happen within procmail.

To extract the *last* occurrence,

  :0B
  * 1^1 ^Wrote file \/.*
  { ATTACHMENT=$MATCH }

but to get all of them (and let's hope that you'll settle for having them
separated from one another with newlines and a trailing newline in the value
(Continue reading)

Timothy J. Luoma | 1 Apr 21:57 2001
Picon

extracting attachments


After getting one too many enormous GIFs by someone who is digital camera
happy...
...after all the virii going around...
...after hearing about all the different buffer overflows and other exploits
related to HTML emails and whatnot...
...after getting 15 copies of a large executable by someone who claimed I "GOTTA
SEE THIS"...

I have sworn off email attachments for the rest of my life.

Now the problem is that some of them are necessary, and most people (that I deal
with) don't have a clue how to put something on a web page rather than emailing
it.

And I'd rather not have to login to the server and manually extract it anytime I
get an email either

So I came up with an idea:

	Use metamail to extract the attachment to a directory accessible via the web.

	Add the URL to the attachment so that if I want to download it, I can just
click the link

CONCERN:

	Could some mean person muck with the Content-Type and Content-Disposition
definitions, ie instead of this:

(Continue reading)

Re: extracting attachments

At 15:57 2001-04-01 -0400, Timothy J. Luoma wrote:

>I have sworn off email attachments for the rest of my life.

For some simple lists I run through procmail recipes, I run the incoming 
messages through an attachment filter called stripmime 
<http://www.phred.org/~alex/stripmime.pl> that strips them entirely, then 
emits a footer text into the message indicating pieces have been removed 
(problem was having a stated policy of "no attachments" didn't sink in with 
people).  I did some of my own tweaks to the helper app, and I would think 
it could be tweaked to support what you're trying to do as well -- the 
message itself could have the URL tacked right into the footer.

Actually, in the procmail rules on that account, I separatley check for 
multipart and bounce a reminder text, THEN the MIME stripper is invoked as 
a filter to eliminate everything except text/plain.

If you wanted to get really clever, the helper app could check to see if 
the extracted attachment was the same as another (CRC32/size signature 
possibly, followed by an outright comparison), and just point to 
that.  Then you don't have multiple copies of the same binary hanging on 
your system (or of those damn .VCFs).  With a helper script on the 
webserver (perl cgi, or a PHP-enabled page), the URLs could point into this 
helper which could manage renaming things to their original names (multiple 
attachments with different names but the same content) and enforcing http auth.

>Content-Disposition: inline; filename="../../../../../../../../../../.rhosts"

1. Would require that the user under which procmail is being executed has 
write perms to that _system_ file (arguably just another reason why root 
(Continue reading)

Andrew Kenna | 2 Apr 07:26 2001
Picon

Recipies

I have a procmail recipie that I want to make run on 5 different domains
that are configurd under sendmail... What steps will I need to take so this
will happen ? 

Andrew
Timothy J. Luoma | 2 Apr 14:35 2001
Picon

RE: Suspicious rcfile...


1) Please do not send attachments to the list (or any list that does not
expressly permit it)

2) Please do not send HTML formatted messages to the list (or any list that does
not expressly permit it)

3) Please see 'man procmail' for an explanation of the term 'Suspicious rcfile'
Jill Bird | 2 Apr 15:13 2001
Picon

"if this then that" logic doesn't seem to work

Can anyone help me with this?

testing.rc - INTENT is to check 2 items before checking the body. If the
>From and Subject match - then check the body for a particular string (in
this case: xxff).  If all of this matches, resend the message to a
particular mail address AND put a copy in my mail folder OTHERWISE -
just put a copy in my mail folder.

:0
* ^From.123247N <at> knotes.kodak.com
* ^Subject:.*test
{
        :0 B
        *xxff
        :0 c
        ! bird <at> cyber.kodak.com
        :0
        in-testing
}

The log file shows the following:

procmail: Assigning "INCLUDERC=/home/bird/Procmail/testing.rc"
procmail: Match on "^From.123247N <at> knotes.kodak.com"
procmail: Match on "^Subject:.*test"
procmail: No match on "xxff"
procmail: Skipped "! bird <at> cyber.kodak.com"
procmail: Assigning "LASTFOLDER=in-testing"
procmail: Opening "in-testing"
procmail: Acquiring kernel-lock
(Continue reading)

Trevor Jenkins | 2 Apr 15:44 2001

Re: Modify "Subject:"

On Thu, 29 Mar 2001, Timothy Luoma <elists <at> 1stpc.org> wrote:

> > How can I use "formail" to modify the "Subject:aaaaaaa"
> > to "Subject: [NNNN] aaaaaaa"?
> 
> :0fhw
> * ^Subject:\/.*
> | formail -I"Subject: [NNNN] $MATCH"

That's the easy part. :-) Helps with those lists that do not insert tag
lines at all. But I'd like a generic solution so that I don't have to
write a separate rule for each list. Ratehr I want to have a single rule
and then have a "table" of list addresses and their appropriate tag.

However, I and several others (e.g. Ashley M. Kirchner <ashley <at> pcraft.com>
who asking on Wednesday 28 Feb 2001) want an even more generic solution.
Many of the lists I subscribe to already have such tags in the subject
line. I don't want to go adding more and more and more of these tags so a
subject line but would like to normalise them.

For example, I subscribe to several lists to which messages are often
cross posted. Depending upon the copy that someone might reply to the
subject line can end up as

"Subject: [AAAAA] [BBBB] [CCCCC] Blah Blah Blah"

I'd like to change it so that each copy has only the tag for its list. It
becomes a little complicated when "Re: " appears in there. So one might
have

(Continue reading)

Don Hammond | 2 Apr 17:20 2001

Re: "if this then that" logic doesn't seem to work

On  2 Apr, Jill Bird wrote:
| Can anyone help me with this?
| 
| testing.rc - INTENT is to check 2 items before checking the body. If the
| >From and Subject match - then check the body for a particular string (in
| this case: xxff).  If all of this matches, resend the message to a
| particular mail address AND put a copy in my mail folder OTHERWISE -
| just put a copy in my mail folder.
| 
| :0
| * ^From.123247N <at> knotes.kodak.com
| * ^Subject:.*test
| {
|         :0 B
|         *xxff
|         :0 c
|         ! bird <at> cyber.kodak.com
|         :0
|         in-testing
| }
| 
| The log file shows the following:
| [...]

It's *so* refreshing to have someone include the relevant log output.
Each of these might have been clues:

| procmail: Skipped "! bird <at> cyber.kodak.com"
| procmail: Skipped "! bird <at> cyber.kodak.com"

(Continue reading)

Wade A. Mosely | 2 Apr 17:13 2001

Re: "if this then that" logic doesn't seem to work

Don Hammond wrote:
<excerpted>
> At any rate, one way you might do this is something like:
> 
> :0
> * ^From.123247N <at> knotes.kodak.com
> * ^Subject:.*test
> {
>         :0 Bc
>         *xxff
>         ! bird <at> cyber.kodak.com
>         :0 A:
>         in-testing
> }
> 
> Your second (non)recipe in the block has been eliminated and the "c"
> flag moved up to the first recipe.  An "A" flag has been added to the
> second recipe to say execute this recipe if the condition matched on the
> previous recipe (without an "a" or "A" flag at the same nested block
> level).  Since there is no condition on this recipe, the action is done
> if the previous recipe matched.  The trailing colon ":" tells procmail
> to use a lock file while writing to the file in-testing.

I am fairly new to using procmail.  I am curious: Is the
following recipe functionally equivalent?  Is there any reason to
not simplify it in this manner?  (I am thinking that Don
Hammond's solution is less resource intensive, since it only
egreps the body if the previous conditions match.  Am I correct?)

:0
(Continue reading)


Gmane