procmail: Why does the receipt not match here?
Ronald Fischer
:0
* ^Subject: Postmaster notify: see transcript for details
{
....
}
and the mail message contains
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="i14ImYk07525.1075920516/fusshuhn.de"
Subject: Postmaster notify: see transcript for details
Auto-Submitted: auto-generated (postmaster-notification)
but the procmail logfile says:
From MAILER...@fusshuhn.de Wed Feb 4 19:48:36 2004
Subject: Postmaster notify: see transcript for details
...
procmail: No match on "^Subject: Postmaster notify: see transcript for details"
Why doesn't my rule match here?
Alan Connor
Do you have one or more spaces before the newline after ...details
in your .procmailrc?
AC
Alan Clifford
RF> This is weird: My .procmailrc contains a receipt
RF>
RF> :0
RF> * ^Subject: Postmaster notify: see transcript for details
RF> {
RF> ....
RF> }
RF>
RF> and the mail message contains
RF> Subject: Postmaster notify: see transcript for details
RF>
RF> Why doesn't my rule match here?
RF>
Did you cut-and-paste your actual recipe to your post? If not, please
do so so we can have a look at it.
Alan
( If replying by mail, please note that all "sardines" are canned.
There is also a password autoresponder but, unless this a very
old message, a "tuna" will swim right through. )
Alan Clifford
RF> This is weird: My .procmailrc contains a receipt
RF>
RF> :0
RF> * ^Subject: Postmaster notify: see transcript for details
RF> {
RF> ....
RF> }
RF>
RF> and the mail message contains
RF>
RF> MIME-Version: 1.0
RF> Content-Type: multipart/report; report-type=delivery-status;
RF> boundary="i14ImYk07525.1075920516/fusshuhn.de"
RF> Subject: Postmaster notify: see transcript for details
RF> Auto-Submitted: auto-generated (postmaster-notification)
RF>
RF> but the procmail logfile says:
RF>
RF> From MAILER...@fusshuhn.de Wed Feb 4 19:48:36 2004
RF> Subject: Postmaster notify: see transcript for details
RF> ...
RF> procmail: No match on "^Subject: Postmaster notify: see transcript for details"
RF>
RF> Why doesn't my rule match here?
RF>
I this part of the body rather than the header? If so, you need
:0 B
Ronald Fischer
No; you can see this from the procmail log file, when it uses quotes to delimit
the regexp: No match on "...". If there were trailing spaces, they would be
visible just before the closing quote.
Ronald
Alan Connor
That's likely but not certain. Procmail can be quirky. A wise man would
double-check.
Or did you think I posted that just because I was bored?
(sarcasm intended because it was deserved)
It shouldn't matter whether there are spaces there or not, for that matter...
When you can't see anything wrong, but you know something is, you start
looking somewhere...
>
> Ronald
Might be some other invisible character, like a CR or ^L or something.
Did you paste that in or type it?
Open your .procmailrc in ed and enter:
%l
to see what's there.
And do the same for the mail: The problem could be there. I've seen a
lot of Subjects with non-printing characters in them that can really
screw things up.
AC
Ronald Fischer
> Did you cut-and-paste your actual recipe to your post? If not, please
> do so so we can have a look at it.
Yes, only that I replaced the nested recipe (which does not matter here)
by "....".
Ronald Fischer
> RF> From MAILER...@fusshuhn.de Wed Feb 4 19:48:36 2004
> RF> Subject: Postmaster notify: see transcript for details
> RF> ...
> RF> procmail: No match on "^Subject: Postmaster notify: see transcript for details"
> RF>
> RF> Why doesn't my rule match here?
> RF>
>
> I this part of the body rather than the header? If so, you need
>
> :0 B
I'm matching against the Subject line - and this is always in the header.
Ronald
Your name
* ^Subject:.*Postmaster notify: see transcript for details
or just going
* ^Subject:.* see transcript for details
Allodoxaphobia
Even _that_ could be dicey.
There may be a <TAB>, not a blank, 'twix the "notify:" and
the "see". Worse, there could be, IIANM, a <TAB> between
the "Subject:" and the ...actual_subject_text...
I'd just test for
* ^Subject:.*Postmaster notify.*details
and 'endure' the one false hit per decade that may occur.
Jonesy
--
| Marvin L Jones | jonz | W3DHJ | OS/2
| Gunnison, Colorado | @ | Jonesy | linux __
| 7,703' -- 2,345m | config.com | DM68mn SK
Ronald Fischer
> On 5 Feb 2004 01:11:48 -0800, Ronald Fischer <ron...@eml.cc> wrote:
> > No; you can see this from the procmail log file, when it uses quotes to delimit
> > the regexp: No match on "...". If there were trailing spaces, they would be
> > visible just before the closing quote.
>
> That's likely but not certain. Procmail can be quirky. A wise man would
> double-check.
>
> Or did you think I posted that just because I was bored?
>
> (sarcasm intended because it was deserved)
No, I thought you overlooked it (no sarcasm intended).
But I should have posted that checking for trainling spaces in my original
file was the first thing I had done anyway. It was just in hindsight that
I thought that the logfile would be a better indication for the prove
against trainling spaces, because this can be verified by every reader,
while as for the manual checking for trailing spaces, you had to rely
on my word.
> Might be some other invisible character, like a CR or ^L or something.
> Did you paste that in or type it?
I used copy and paste from an xterm window (showing an existing message
as a template) into emacs. Though it is unlikely that there are hidden
characters, I will check it (right now I don't have access to the file).
> And do the same for the mail: The problem could be there. I've seen a
> lot of Subjects with non-printing characters in them that can really
> screw things up.
That's a good point! I haven't thought of this. Will check it too.
Ronald
Alan Connor
Just to be sure about such things, I usually use regexes like this:
* ^Subject:.*word.*word.*word
Let us know what you find.
AC
Ronald Fischer
> Just to be sure about such things, I usually use regexes like this:
>
> * ^Subject:.*word.*word.*word
which could, of course, match too much.
I double-checked my .procmailrc and the incoming message with od -cx,
and both looked fine.
The strange thing is that a *local* test of a message, which slipped through
the condition, worked as expected.
I'm now following the strategy to try out different patterns, from
very coarse (matches nearly everything) to very narrow (matching
exactly the string I'm looking for). All these matches are encoded
in non-delivery recipes and produce only log file entries.
And in case you wonder why I want to match exactly for this string:
My ISP recently introduced SpamAssassin to detect spam. When SpamAssassin
bounces a message because it thinks it is spam, the bounced address
is very often illegal, so the bounce comes back to me and lands in
my inbox. My idea is to catch these re-bounces and throw them away.
I can recognize many of them by the aforementioned subject line
and the fact that the message body contains certain traces to SpamAssassin.
Ronald
Alan Connor
>
>
> Alan Connor <zzz...@xxx.yyy> wrote in message news:<UgIUb.16268$uM2....@newsread1.news.pas.earthlink.net>...
>> Just to be sure about such things, I usually use regexes like this:
>>
>> * ^Subject:.*word.*word.*word
>
> which could, of course, match too much.
Nah. The odds of those 'words' showing up in that order in some other subject
are infinitesimal.
>
> I double-checked my .procmailrc and the incoming message with od -cx,
> and both looked fine.
I'm surprised...
>
> The strange thing is that a *local* test of a message, which slipped through
> the condition, worked as expected.
>
> I'm now following the strategy to try out different patterns, from
> very coarse (matches nearly everything) to very narrow (matching
> exactly the string I'm looking for). All these matches are encoded
> in non-delivery recipes and produce only log file entries.
>
> And in case you wonder why I want to match exactly for this string:
> My ISP recently introduced SpamAssassin to detect spam. When SpamAssassin
> bounces a message because it thinks it is spam, the bounced address
> is very often illegal, so the bounce comes back to me and lands in
> my inbox. My idea is to catch these re-bounces and throw them away.
> I can recognize many of them by the aforementioned subject line
> and the fact that the message body contains certain traces to SpamAssassin.
>
> Ronald
Good luck. Keep us posted.
Because of spam and viruses, mail is really screwed up right now, and it isn't
going to get any better.
I think we Linux Runners need to set up a mail network using non-standard
ports and allowing only registered users access.
But that IS another topic altogether, isn't it?
AC
Ronald Fischer
.procmailrc
to give even more information of what is going on, and the mystery is
even
greater. I present here the excerpt of my .procmailrc literally, and
also the excerpt of the Logfile, even if this means that I have to
post
a lot. Sorry for this:
==== Excerpt of .procmailrc
:0
* ^Subject: Returned mail: see transcript for details
* ^Auto-Submitted: auto-generated.*failure
* ^To:.+cha.verde@bigfoot.com
!cat >/dev/null
:0 c
* ^Subject: Postmaster notify: see transcript for details
{
VL="Erwarteter Match $$ $EOL"
:0
/dev/null
}
:0 c
* see transcript
{
VL="Minimaler Match $$ $EOL"
:0
/dev/null
}
:0
* ^Subject: Postmaster notify: see transcript for details
{
VL="Teste cha.verde $$ $EOL"
:0 B:
* ^To: cha....@bigfoot.com
* ^X-MailScanner-SpamCheck: spam
probably_dev_null
}
VL="Nicht probably_dev_null $$ $EOL"
==== end of excerpt
Note that the recipe in question is the last one, where the mail,
on a match, should go to folder probably_dev_null.
=== start of corresponding excerpt of logfile
procmail: No match on "^Subject: Returned mail: see transcript for
details"
procmail: Match on "^Subject: Postmaster notify: see transcript for
details"
procmail: Forking "procmail"
procmail: Match on "see transcript"
procmail: Forking "procmail"
procmail: Match on "^Subject: Postmaster notify: see transcript for
details"
procmail: Assigning "VL=Teste cha.verde 21218
"
procmail: No match on "^To: cha....@bigfoot.com"
procmail: Assigning "VL=Nicht probably_dev_null 21218
"
procmail: Match on "(^(Mailing-List:|Precedence:.*(junk|bulk|list)|To:
Multiple recipients of |(((Re
sent-)?(From|Sender)|X-Envelope-From):|>?From
)([^>]*[^(.%@a-z0-9])?(Post(ma?(st(e?r)?|n)|office)|(s
end)?Mail(er)?|daemon|m(mdf|ajordomo)|n?uucp|LIST(SERV|proc)|NETSERV|o(wner|ps)|r(e(quest|sponse)|oo
t)|b(ounce|bs\.smtp)|echo|mirror|s(erv(ices?|er)|mtp(error)?|ystem)|A(dmin(istrator)?|MMGR|utoanswer
))(([^).!:a-z0-9][-_a-z0-9]*)?[%@>
][^<)]*(\(.*\).*)?)?$([^>]|$)))"
procmail: [21221] Tue Feb 10 16:31:27 2004
procmail: Assigning "VL=Erwarteter Match 21221
"
procmail: Assigning "LASTFOLDER=/dev/null"
procmail: Opening "/dev/null"
procmail: Notified comsat: "a9832432@0:/dev/null"
From MAILER...@fusshuhn.de Tue Feb 10 16:31:27 2004
Subject: Postmaster notify: see transcript for details
Folder: /dev/null
5667
procmail: [21222] Tue Feb 10 16:31:27 2004
procmail: Assigning "VL=Minimaler Match 21222
"
procmail: Assigning "LASTFOLDER=/dev/null"
procmail: Opening "/dev/null"
procmail: Notified comsat: "a9832432@0:/dev/null"
From MAILER...@fusshuhn.de Tue Feb 10 16:31:27 2004
Subject: Postmaster notify: see transcript for details
Folder: /dev/null
5667
procmail: Executing "/usr/sbin/sendmail,-oi,ronald....@i-dial.de"
procmail: Assigning "LASTFOLDER=/usr/sbin/sendmail -oi
ronald....@i-dial.de"
procmail: Notified comsat: "a9832432@:/usr/sbin/sendmail -oi
ronald....@i-dial.de"
From MAILER...@fusshuhn.de Tue Feb 10 16:31:27 2004
Subject: Postmaster notify: see transcript for details
Folder: /usr/sbin/sendmail -oi ronald....@i-dial.de
5610
==== end of excerpt of logfile
The incoming mail has the subject
Subject: Postmaster notify: see transcript for details
so the first recipe fails as expected.
The second recipe matches as expected. The copy of the mail is dumped
to /dev/null, and because of the c flag processing continues.
The third recipe matches too, as expected, and again because of the
c flag, processing continues.
Now the mystery starts. I get now NO INFORMATION at all anymore
in the logfile about the 4th recipe. Instead, procmail says that it
passes my message on to sendmail, which then delivers it to my home
address. Note that neither the 'VL=...' line inside the block of
the 4th recipe, nor the 'VL=...' line after the 4th recipe, is logged.
What on earth is going on here????
Ronald
Ronald Fischer
> Good luck. Keep us posted.
I've got the impression that the strange behaviour could be a sign of a
concurrency problem. I have introduced a global lockfile, and since then,
the recipes behave normal. I will have to observe the case closesls over
the next few days, though.
Ronald
Alan Connor
What do you mean by a "global lockfile"? You use the same one for every
recipe?
AC
--
ed(1)
Check out the original tutorials by Brian W. Kernighan:
----- http://tinyurl.com/2uprx -----
If it's good enough for BWK, it's good enough for me.
Ronald Fischer
> What do you mean by a "global lockfile"? You use the same one for every
> recipe?
'lock', not 'log'.
I'm using now a
LOCKFILE=....
at the beginning of my .procmailrc, to sequentialize processing (as you had
advised me in a separate thread). This is, according to the "Procmail Compagnion",
called a "global lockfile".
Ronald
Alan Connor
>
>
> Alan Connor <zzz...@xxx.yyy> wrote in message news:<6UJWb.1099$tL3...@newsread1.news.pas.earthlink.net>...
>> What do you mean by a "global lockfile"? You use the same one for every
>> recipe?
>
> 'lock', not 'log'.
That's what it says above: "lock"
>
> I'm using now a
>
> LOCKFILE=....
>
> at the beginning of my .procmailrc, to sequentialize processing (as you had
> advised me in a separate thread). This is, according to the "Procmail Compagnion",
> called a "global lockfile".
>
Not me.
I have, >>obviously<< (before your previous post on this thread) never
heard of a global lockfile for procmail.
You need some sleep.
AC