gmane.mail.procmail

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

(unknown)

Zhiliang — 2012-02-09T20:32:22

I have the following procmail recipe to auto-respond upon certain
criteria.  The recipe "works" in the way to match and to send reply email;
however the sent email only has mail header without mail body (empty), 
that I could not get it why mail body is "not formed" or "not sent":

SUBJADDR =`formail -xSubject: |perl -pe 's/.*sub.*\s+([^\s]+\< at >[^\s]+)/$1/sg;s/^\s+//g;s/\s+$//g;'`
HISTMARK = `date +"%s"`

:0
* ^TO.*watchdog< at >my.domain
| (formail -i"Subject: Confirmation needed" \
       -I "To: $SUBJADDR"; \
       echo " "; \
       echo " "; \
       echo "Confirmation mark: $HISTMARK") | $SENDMAIL -oi $SUBJADDR

I tried single or double 'echo " ";' lines to leave 1 or 2 space lines 
between mail header and body - that makes no difference.  Any suggestion 
would be appreciated.

Zhiliang

Re: Organizing

Professional Software Engineering — 2011-11-10T14:29:50

So?  You can still run the stuff "for all users" in the global 
procmailrc, then fall through to their personal .procmailrc configs.

---
  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: Organizing

LuKreme — 2011-11-10T05:03:17

That’s one thing I am not having to deal with. We just have the one mailserver and that isn’t king to change.


Both, really.


Because some users will have their own .procmailrc files they want to run. Also, I find that the intersection of people who can grok plus addressing and people who cannot grok a simple .procmailrc is near enough to nil as makes no difference


The global config doesn’t actually *do* anything. It sets a bunch of variables (CLEANFROM, etc), sets a header if the message can in on a spoofed local IP, and it backsup the message. Frankly, if users want to opt-out of the header, they can simply remove it.


That’s a good idea.