gmane.mail.procmail

Re: PARP ::was::::Re: procmail abandonded?

Jerry K — 2012-05-25T02:40:29

Hello LuKreme,

Thank you for your reply!

Please see inline comments

On 05/24/12 05:21 PM, LuKreme wrote:

After reviewing the web site and the documentation, I had similar
thoughts.  I really just wanted to bounce it off the mailing list
community and see if I was missing something.




I am at the same spot.  I had a "wild hair" yesterday to go search
around for either a replacement, or to see if there were any efforts to
update procmail or fork it.  Sadly, nothing on the procmail/procmail
fork front.

I reviewed Sieve, Mail Drop and a couple of others.  PARP was one I had
not seen previously.

As dated as procmail is in its current state, there is still nothing
else out there that does as much as it does.

Again,  thank you for your reply,

Jerry

Re: PARP ::was::::Re: procmail abandonded?

LuKreme — 2012-05-24T22:21:50

Jerry K spake on Wednesday 23-May-2012< at >19:46:38

Well, yes. The pluses are rather large, but the minuses are rather larger. I can't see using something like this for an entire site, for example. It seems targeted at specific types of filtering, and is not a general purpose tool like procmail.

I am getting less an less happy with procmail, honestly. It takes more effort to deal with some types of mail that are much more common today than they were 10-15 years ago, but I haven't found anything that I thought was worth the effort of switching to, either.

PARP ::was::::Re: procmail abandonded?

Jerry K — 2012-05-24T01:46:38

Has anyone looked at/or is using PARP as a procmail replacement?

http://adamspiers.org/computing/parp/

In my brief review, it seems to have several pluses and minuses.

Thanks for any comments,

Jerry


On 10/14/10 12:29 PM, Ed Blackman wrote:

Re: detect an email with japanese characters

LuKreme — 2012-05-23T22:19:17

PSE-L< at >mail.professional.org (Professional Software Engineering) spake on Tuesday 22-May-2012< at >21:58:42

furrin.rc does a pretty decent job, but i there are no habit characters in the subject, as there often aren't, then it fails on utf-8 encoded foreign spam. OTOH, body checks for habit seem a rather high price to pay.

Re: detect an email with japanese characters

Professional Software Engineering — 2012-05-23T03:58:42


One late arrival:

Check out "furrin.rc" at:

<http://www.professional.org/procmail/spam.html>

That groups various character sets and checks for hibit characters, 
etc.  There are a number of links to references and pertinent RFCs as well.

I wrote it quite a few years ago (last time that was even altered was 
9 years ago), and it's been quite effective for me.

---
  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.

Re: detect an email with japanese characters

Konstantin — 2012-05-23T02:33:43

Great! Thank you all for suggestions.

Konstantin.



On 5/21/2012 4:32 PM, Alan Clifford wrote:

Re: detect an email with japanese characters

Robert Bonomi — 2012-05-22T02:44:45

In 'western' usage, it is exceedingly rare to -need- anything beyond the 
so-called C0 through C3 glyph sets (roughly 256 'printable' symbols).

Microsoft is well known for it's egregious MISUSE of UTF-8 multi-byte 
glyphs.  *Especially* in documents that are identified as using something 
_other_ than UTF-8.  One simply cannot 'trust' MS products to get the 
'content-type' right.  Their products are notorious for, say, _declaring_
a document as 'iso-8859-1' or 'Windows-1251', but including in that 
document a handful of UTF-8 3-byte sequences from the '0xe2', '0xe7', 
and '0xef' ranges.  

For processing arbitrary e-mail from a Microsoft product, one has to
essentially throw away the declared charset, parse out the 'valid'
ASCII/ISO-8859/WINDOWS-125x/UTF-8 glyphs that one can recognize, and
do 'something sensible' with 'whatever is left unrecognied'.

It takes a couple of hundred lines of 'C' code to convert a putative
ASCII/ISO-8859/WINDOWS-125x/UTF-8 document to a consistent format,
say ISO-8859-1.  I kn

Re: detect an email with japanese characters

LuKreme — 2012-05-22T01:31:42


Oh, it's not just MSFT, there are many high byte characters in UTF-8 that are perfectly usable and proper. The days of 7-bit email are long behind us, and that's a good thing.

Re: detect an email with japanese characters

Robert Bonomi — 2012-05-21T23:25:17

 Konstantin <klk206< at >panix.com> wrote:

What I do is:

  a) specify a list of charsets that I understand:

     OK_CHARSET=(ASCII|DISPAY|ISO-8859-[12]|WINDOWS-125[012]|utf-8|utf8)

  b) filter anything that (1) specifies charset, and (2) does -not- have
     one of those charsets:h

     :0 H
     * ^(From|To|Subject): *\=\?\?.*
     * ! $ MATCH ?? ${OK_CHARSET}
     $DISCARD

     :0 H
     * ^Content-Type:.*charset\/.*
     * ! $ MATCH ?? ${OK_CHARSET}
     $DISCARD

  c) for 'foreign language' issues, I look for 'commonly occuring' 
     character-sequences (presumbly 'words', but, since I don't speak
     the languge, i'm not -sure- of that:) and look for any of several
     such (presumed) 'words' in the message body.  e.g.:
       for German (which I understand, a little):
        :0 H
        * ^Subject:.*\<(aufmachen|und|der|Ihr|Ihre|Veil|Zeit)\>
        $DISCARD

       for Italian (which I don't):
        :0 EH
        * ^Subject:.*\<(aviso|limitazione|posteitaliane|Urgente|attenzione|logiciel|pros

Re: detect an email with japanese characters

Robert Bonomi — 2012-05-21T21:52:33

Re: detect an email with japanese characters

Alan Clifford — 2012-05-21T20:32:03

Konstantin wrote (at 14:59 (-0400) on Monday, 21st May, 2012):


I took a copy of this some time ago.  It might be useful

http://clifford.ac/chinese.html

The mentioned files are in chinese.zip


Alan

detect an email with japanese characters

Konstantin — 2012-05-21T18:59:41

Hi,

How it is possible to detect (and filter) an email written in Japanese characters (which I cannot read anyway)?

The content-Type specifies charset="utf-8". The "From" field is apparently invalid, and may not necessarily contain .jp

Regards,
Konstantin.

Re: Playing a sound

Bennett Todd — 2012-04-18T17:53:53

After extracting the name of the sender, or the list to which it was sent,
or whatever, maybe assemble a text announcement and pipe it into flite
(festival light, text-to-speech in one compact executable).
____________________________________________________________
procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail< at >lists.RWTH-Aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/procmail

Re: Playing a sound

Danny — 2012-04-18T17:46:02

Thank you all guys ... appreciated ... I now know more or less what to do ...

Danny

Re: Playing a sound

Alan Clifford — 2012-04-18T17:25:07

Danny wrote (at 21:27 (+0200) on Tuesday, 17th April, 2012):



I remember trying this and I still have the recipe commented out in my 
procmail files:

FROMHEADER=`formail -c -rtz -x To:`
# play sound
# DUMMY=`test -f "${PMDIR}/mailsounds/${FROMHEADER}.wav" \
# && play "${PMDIR}/mailsounds/${FROMHEADER}.wav" > /dev/null &`


I had a directory with sounds:

alan< at >malander:~$ ls ~/.procmail/mailsounds/
alanclifford\< at >gmail.com.wav  test2\< at >clifford.ac.wav  test\< at >clifford.ac.wav


I don't sit at that computer any more since I got a laptop.


Alan

(  Please address personal email to alan+1< at > as email to lists< at >
    is only read from my subscribed lists. )

Re: Playing a sound

LuKreme — 2012-04-18T04:34:03

Danny squawked out on Tuesday 17-Apr-2012< at >13:27:32

Yep, it's quite easy. On the tried period of time that I was running postfix/procmail on my OIS System I had a recipe that looked something like this on my personal account. I set UNAME by indexing the CLEANFROM against a whitelist local file.

user< at >domain.tld Fred Smith

# This is a non-delivery recipe
:0
* CLEANFROM ?? $UNAME
{ DUMMY=`/usr/bin/say "New mail has arrived from $UNAME" -v Alex -r 255` }

Of course, the command that you use will vary by OS, but it really is that simple. The hard part was building UNAME, which I did with a local file that I edited manually when I wanted notifications from a person.

But the experiment of running postfix and procmail on OS X was short-lived, and my servers are miles away, so sound playing would be rather silly at this point.

You can do pretty much anything you want in a recipe, and executing it from a fake variable assignment avoids a lot of issues.

Re: Playing a sound

Robert Bonomi — 2012-04-18T03:45:58

`

Yes, procmail is -capable- of doing it.  To wit;

    :0 c:
    * ^From:.*${ADDRESS}
    | ${PLAYSOUND}

However _system_ restrictions may prohibit it.  e.g. system-enforced access
controls may allow only the user logged in on the 'console' to access the
audio device.

More than two decades ago, in a _production_ business environment, I 
deployed a routine on user workstations that submitted a job to a remote 
mainframe.  when the 'completion status' mail came back one of two sound-
effects would play, depending on whether the job completed sucessfully or
failed.  Picked from the 'standard' samples that came with the O/S release,
they were a 'gong' for a successful run, and a 'toilet flushing' for the
other case.   One day, a new user got the submitted data wrong for something
like 20 consecutive attempts.  When he -finally- got the 'gong', he got a
round of applause from everybody within earshot.  *GRIN*

Re: Playing a sound

Professional Software Engineering — 2012-04-17T19:57:47

:0
* ^From:.*\<some_address< at >domain\.tld
{
         # c - make a copy for purpose of invoking a sound processor
         # i - ignore write errors (say, because your invoked program doesn't
         # give a hoot about stuff on stdin)
         :0ci
         | path/to/some/sound/player soundfile

         # original processing continues here (say you want to file it special
}


The \< isn't literal open bracket, it's regexp for "character before 
or after a word, and of course, the above could be simplified to more 
specifically what you asked for:

# this doesn't copy the message, so it effectively gets tosssed when invoking
# the sound player.
:0i
* ^From:.*\<some_address< at >domain\.tld
| path/to/some/sound/player soundfile


YOU need to find a suitable audio player.  It's an exercise for you 
to resolve hardware permissions (can your user account play sound, or 
only root?)

---
  Sean B. Straw / Professional Software Engineering

  Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>

Re: Playing a sound

Danny — 2012-04-17T20:02:00

Hi,

I am running Debian ... I think I know how to do it now ...

Thank You

Danny

Re: Playing a sound

Andrew Edelstein — 2012-04-17T19:54:42

That depends on your operating system, is your mailbox server also your 
workstation, etc.
Generally, assuming your workstation is the same machine where Procmail 
is running, this is fairly trivial. You just need the "action" of your 
procmail recipe to include calling your sound player program, presumably 
telling it what sound file to play. You may have to monkey around with 
user/permissions a bit so that the user that's running the procmail 
script has permission to access your sound device. Presumably if 
procmail is being run as you, and you are logged into X windows, this is 
a non-issue as you will have permission to access the sound device.

Playing a sound

Danny — 2012-04-17T19:27:32

Hi guys,

Is it possible to play a soundfile when procmail encounters mail from a certain
e-mail address?

Thank You

Danny