headers
Professional Software Engineering | 1 Aug 2008 17:07

Re: new recipe filter...

At 07:24 2008-07-30 +0200, Michelle Konzack wrote:
> > :0 f
> > * > 2048000
> > | ${FORMAIL} -A"X-Note: Oversize/Not Filtered"
> >
> > Works a treat.
>
>Here is nothing moved.  FORMAIL add only a Header.

Well, it'd make a lot of sense to add the 'h' flag there, so that ONLY the 
header of the large email were passed to formail to be modified...

---
  Sean B. Straw / Professional Software Engineering

  Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
  Please DO NOT carbon me on list replies.  I'll get my copy from the list.
Permalink | Reply | 0 comments |
headers
Jake Di Toro | 5 Aug 2008 20:01

Mailing list handler

Didn't see this come through, appoligies if this is posted twice:

I've had some recent changes to my mail handling and wanted to
streamline some more.  Dug through the archives for the mailing list
handlers and came up with this as the latest:
http://www.xray.mpe.mpg.de/mailing-lists/procmail/2007-11/msg00028.html 

Was wondering is a) there's been any "upgrades" in the last 9ish
months, and b) if anyone had a file available for download as the
archive has munged up a few lines etc.  I'm sure with a little testing
I'd work out the kinks, but it might be eaiser to have a clean copy to
start testing with.

--

-- 
Till Later, 
Jake <karrde <at> viluppo.net>
Permalink | Reply | 3 comments |
headers
Professional Software Engineering | 6 Aug 2008 19:28

Re: Mailing list handler

At 14:01 2008-08-05 -0400, Jake Di Toro wrote:
>I've had some recent changes to my mail handling and wanted to
>streamline some more.  Dug through the archives for the mailing list
>handlers and came up with this as the latest:
>http://www.xray.mpe.mpg.de/mailing-lists/procmail/2007-11/msg00028.html

It should be noted that while there is a line comment near the top of the 
recipe that says "Sean wrote this", the entirety of that modified recipe 
wasn't written by me, and what was, has been considerably modified.  My 
code is at:

<http://www.professional.org/procmail/listname_id.rc>

(which, as of this writing, I haven't needed to touch in over 4 years - 
both the copy on the website, as well as the identical one that is in 
production)

At the "save all list messages into a directory named"... comment line, it's
code beyond merely identifying the name of the list, and isn't part of the 
intent of my original recipe.  I compartmentalized the recipe to just 
identifying a name for the list, since that can later be used to skip spam 
checking, do custom filing, or whatever.  If someone wants to auto-file, 
they can includerc the id recipe, and then act upon the LISTNAME variable.

There are differences in the order and content of the conditions in the 
recipe you linked to as versus my original.  Toggling of VERBOSE logging on 
and off around one part is consistent with someone tweaking to see what is 
happening in part of the recipe, and isn't part of my original either.  I 
don't have the time right now to examine them and run a saved email corpus 
against them to determine how they interract (though my original still
(Continue reading)

Permalink | Reply | 2 comments |
headers
Remien, Carsten | 8 Aug 2008 09:06
Picon

Add X-Header to see which filter greps

Hi,

I would like to see, which procmail filter has moving my mail to a 
special IMAP folder.
Is it possible to set a X-Header in each filter?
Or is there any other soultion?

Regards,

Carsten
Permalink | Reply | 1 comment |
headers
Jonesy | 8 Aug 2008 15:40

Re: Add X-Header to see which filter greps

On Fri, 08 Aug 2008 09:06:39 +0200, Remien, Carsten wrote:
> Hi,
>
> I would like to see, which procmail filter has moving my mail to a 
> special IMAP folder.
> Is it possible to set a X-Header in each filter?
> Or is there any other soultion?

  #  Kill the %&*((!)(*& "LINK EXCHANGE" emails
  #  10-Apr-07
  :0
   * ^Subject:.*link.exchange
    {
      LOG=">>>> DELETED - Subject: Link exchange $TOHDR $NL"
      :0 fwh
      | formail -I"X-DELETED-SPAM: Subject: Link exchange ${TOHDR}"
      :0:
      $DELETE
    }

Jonesy
--

-- 
  Marvin L Jones    | jonz          | W3DHJ  | linux
   38.24N  104.55W  |   <at>  config.com | Jonesy |  OS/2
    *** Killfiling google posts: <http://jonz.net/ng.htm>
Permalink | Reply | 0 comments |
headers
Scott Moseman | 13 Aug 2008 22:53
Picon

Which grep match?

Let's start from this very basic grep recipe...

* ? formail -x Subject: | fgrep -is -f /etc/procmail/subjects.txt

I will know it matched an entry in the file, but I will not know
*which* entry (from subjects.txt) was matched.  Is there an *easy* way
to process this type of query *and* get the match output?  I suppose
in a worst case I could pipe to a script and go through the
subjects.txt file line by line looking for a match, but there must be
an easier way?

My goal is that I desire to start collecting a "hit count" on the
matches, so I see which ones are matched often and which ones are
rarely matched, if ever.

Thanks,
Scott
Permalink | Reply | 1 comment |
headers
Scott Moseman | 14 Aug 2008 16:03
Picon

Re: Which grep match?

grep -o

I read about that previously on the man page but for some reason
discounted what it was suppose to do, thinking it was not my
intention.  But it appears to do exactly what I'm interested in having
done (at least for grep and fgrep queries, not egrep, but that's fine
for now).

Thanks,
Scott

On Wed, Aug 13, 2008 at 3:53 PM, Scott Moseman <scmoseman <at> gmail.com> wrote:
>
> Let's start from this very basic grep recipe...
>
> * ? formail -x Subject: | fgrep -is -f /etc/procmail/subjects.txt
>
> I will know it matched an entry in the file, but I will not know
> *which* entry (from subjects.txt) was matched.  Is there an *easy* way
> to process this type of query *and* get the match output?  I suppose
> in a worst case I could pipe to a script and go through the
> subjects.txt file line by line looking for a match, but there must be
> an easier way?
>
> My goal is that I desire to start collecting a "hit count" on the
> matches, so I see which ones are matched often and which ones are
> rarely matched, if ever.
>
> Thanks,
> Scott
(Continue reading)

Permalink | Reply | 0 comments |
headers
George Crum | 15 Aug 2008 01:00
Picon
Favicon

Re: dynamci filters

Ok finally got back to this.  Here's what I threw together.  Keep in mind I'm fairly new to procmail.  This is my
second attempt at creating a procmailrc.  I wasn't sure about the action lines and assumed that if I
executed a shell command then I couldn't have the forward action on the next line.  The Subjects are exact
representations of what we'd see.  I have not tested this yet.  Does anyone see any problems that we would
have with this?

# pager on 1st notification and set to not pager until the tmp file is removed
:0 
* ^Subject:.*PROBLEM alert - server123 is CRITICAL
{
        # If file exists then forward to nopager
        :0 
    * ? test -f /tmp/file
    ! nopager <at> domain.com

    # If file does not exist then create file and forward to pager
    :0 iE
    {
        * ? test ! -f /tmp/file
        | touch /tmp/file
        :0
        ! pager <at> domain.com
    }
}

# Received Recovery, remove tmp file and forward to pager
:0 
* ^Subject:.*RECOVERY alert - server123 is OK
{
    :0
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dallman Ross | 15 Aug 2008 01:39

Re: dynamci filters

On Thu, Aug 14, 2008 at 04:00:13PM -0700, George Crum wrote:
> I have not tested this yet.  Does anyone see any problems that we
> would have with this?

> 
> # pager on 1st notification and set to not pager until the tmp file is removed
> :0 
> * ^Subject:.*PROBLEM alert - server123 is CRITICAL
> {
>         # If file exists then forward to nopager
>         :0 
>     * ? test -f /tmp/file
>     ! nopager <at> domain.com
> 
>     # If file does not exist then create file and forward to pager
>     :0 iE
>     {
>         * ? test ! -f /tmp/file
>         | touch /tmp/file
>         :0
>         ! pager <at> domain.com
>     }
> }

I don't think the i-flag does any good on a nested recipe.
You'll probably see an error in your log from that.  It
won't cause anything to do anything untoward, though.

Algorithmically, you don't need to run the same test each
time.  If the first nested recipe failed, then the test is negative and
(Continue reading)

Permalink | Reply | 0 comments |
headers
George Crum | 15 Aug 2008 02:22
Picon
Favicon

Re: dynamci filters

> 

> I don't think the i-flag does any good on a nested recipe.
> You'll probably see an error in your log from that.  It
> won't cause anything to do anything untoward, though.
> 
> Algorithmically, you don't need to run the same test each
> time.  If the first nested recipe failed, then the test is negative and
> you can run the second recipe without a condition line.
> 
> Even the E-flag is superfluous, as is the second (inner) nested-brace
> set, because if the first nested recipe evaluated true, the action
> will have been performed and procmail will have exited already.
> 
> Dallman

Indeed you are correct Dallman.  I tried and saw exactly what you said would happen in the logs.  Here is a
revised version.  Does not seem to be working correctly still.  

1. 1st Problem email received
- It creates the tempfile but does not forward to pager.  Second email received with same subject does show in
log that it is getting forwarded to nopager
2. 2nd Problem email received
- forward email to nopager
3. Recover email received
- tempfile is deleted but no forwarding to pager happens

# pager on 1st notification and set to not pager until the tmp file is removed
:0
* ^Subject:.*PROBLEM alert - server123 is CRITICAL
(Continue reading)

Permalink | Reply | 1 comment |

Gmane