headers
Eric Wood | 12 Jan 2011 22:11
Favicon

Recieved: seperated by Date:

I have a rule that tests for only 1 Recieved header.  If if there's only one Recieved: line the it make sure it from a internal machine ip because short-circuiting the delivery:
 
:0H:
* ! ^Received: .*$+Received: \/.*
* ^Received:.*\(.*\[(10\.0|10\.99|127)\.
$DEFAULT
However, spammer figured to separate the Recieved headers (which are normally listed together) with another header line like Date:
 
Received: from atlanticbb.net (72-28-238-080-dhcp.aik.sc.atlanticbb.net [72.28.238.80])
 by ....
Date: Wed, 12 Jan 2011 15:10:38 -0500
Received: from RONN (localhost [127.0.0.1])
 by ......
 
Therefore I've replace my rule with a counter mechanism:
 
## Count the number of Received Headers (hops)
MAXHOPS=1
:0H
* 1^1 ()(^Received:\ )
{ HOPS = $= }
##
:0H:
* $ ${HOPS}^0
* $ -${MAXHOPS}^0
* ^Received:.*\(.*\[(10\.0|10\.99|127)\.
$DEFAULT
I'm still fuzzy on how the scoring.  I'm sure I've messed up what ^0 and ^1 means.  If someone can straighten me out, I'd appreciate it.

-Eric Wood
 
____________________________________________________________
procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail <at> lists.RWTH-Aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/procmail
Permalink | Reply | 0 comments |
headers
jeff | 14 Jan 2011 08:11

how exactly is INCLUDERC handled?

I am working on optimizing a procmailrc and am thinking about moving some of the larger patterns (lists of email addresses and IP addresses) into their own files and then pulling them in with INCLUDERC only if I need them.  But this would only be advantageous if INCLUDERC is only executed when it is encountered during execution as opposed to being executed when the procmailrc is parsed.  Does anyone know which one it is?

Jeff Orrok
LXVI Internet Services
161 Del Mar Cir
Aurora CO 80011
866-598-4638
303-995-0138
____________________________________________________________
procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail <at> lists.RWTH-Aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/procmail
Permalink | Reply | 5 comments |
headers
Bart Schaefer | 14 Jan 2011 16:21
Picon

Re: how exactly is INCLUDERC handled?

On Thu, Jan 13, 2011 at 11:11 PM,  <jeff <at> lxvi.net> wrote:
> this would only be advantageous if INCLUDERC is only executed when it is
> encountered during execution as opposed to being executed when the
> procmailrc is parsed.  Does anyone know which one it is?

*Everything* in a procmail rc-file is executed when it is encountered.
 There is no separate parsing-only pass, period.
Permalink | Reply | 0 comments |
headers
LuKreme | 14 Jan 2011 18:04
Favicon

Re: how exactly is INCLUDERC handled?

On Jan 14, 2011, at 12:11 AM, jeff <at> lxvi.net wrote:

> this would only be advantageous if INCLUDERC is only executed when it is encountered during execution as
opposed to being executed when the procmailrc is parsed.  Does anyone know which one it is?

Proclaim starts at the first line and continues until either the message is delivered or the end of the file.

The procmailrc is never parsed, executed, nor compiled.
Permalink | Reply | 2 comments |
headers
Bart Schaefer | 14 Jan 2011 19:06
Picon

Re: how exactly is INCLUDERC handled?

On Fri, Jan 14, 2011 at 9:04 AM, LuKreme <kremels <at> kreme.com> wrote:
>
> The procmailrc is never parsed, executed, nor compiled.

Obviously it's parsed and "executed," otherwise there would be no
syntax rules and nothing would ever happen.  The execution is by
interpreter, not direct machine instructions, but it does execute.

The point, however, is that unlike (say) perl, the entire file is not
compiled before interpretation begins.
Permalink | Reply | 1 comment |
headers
Professional Software Engineering | 14 Jan 2011 19:49

Re: how exactly is INCLUDERC handled?

At 10:06 2011-01-14, Bart Schaefer wrote:
>The point, however, is that unlike (say) perl, the entire file is not
>compiled before interpretation begins.

Another way of putting this for the non-programmer types is that you 
can have a glaring syntax failure somewhere in your procmailrc, but 
so long as the execution never reaches that point, you'll never be 
made aware of it.  In a compiled environment, the program isn't 
executed until the language syntax validates (you can still have 
buffer overruns, etc, but those are runtime failures, not language syntax).

The parse-as-you-go nature of procmail is in many ways a stumbling 
block, but at the same time, it also allows people to create 
includerc's on the fly.

---
  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
LuKreme | 15 Jan 2011 01:33
Favicon

Re: how exactly is INCLUDERC handled?

On Jan 14, 2011, at 11:06 AM, Bart Schaefer <barton.schaefer <at> gmail.com> wrote:

> Obviously it's parsed and "executed," otherwise there would be no
> syntax rules and nothing would ever happen.  

I would not call that executed. The file is read, line by line, and each line is interpreted. To me, executed
implies a binary file or a executable script that can run "on its own" Parsing means preloading the file
and, well, parsing it. 

> The execution is by
> interpreter, not direct machine instructions, but it does execute.

The interpreter executes and interprets the file. However, this is just semantics. 

> The point, however, is that unlike (say) perl, the entire file is not
> compiled before interpretation begins.

Or even preloaded and parsed like a perl script can be, or php, python, &c

All I was trying to make clear is that a procmailrc is just read line-by-line until delivery or EOF
Permalink | Reply | 0 comments |
headers
Richard Reina | 21 Jan 2011 17:49
Picon

getmail not deleting messages after they've been downloaded.

Hope I don't offend anyone by asking a getmail question on the procmail list.  But, I use getmail to get messages over to procmail.  The problem I'm having is that getmail keeps downloading the same messages over and over -- despite being told not to.  I can't get getmail to delete them after they're downloaded.

Can anyone tell me what I'm doing wrong?

Here's my getmailrc

[options]
delete = true
read_all = false
message_log = ~/.getmail/log
message_log_verbose = true

[retriever]
type = SimplePOP3Retriever
server = mail.mxes.net
username = ruliap <at> tuffmail.com
password = xxx


[destination]
type = MDA_external
path = /usr/bin/procmail

____________________________________________________________
procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail <at> lists.RWTH-Aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/procmail
Permalink | Reply | 6 comments |
headers
sharad.kanekar@gmail.com | 21 Jan 2011 18:54
Picon
Gravatar

RE: getmail not deleting messages after they've been downloaded.


Sent from my Nokia phone
-----Original Message-----
From: Richard Reina
Sent:  21/01/2011 10:19:44 pm
To: procmail <at> lists.rwth-aachen.de
Subject:  getmail not deleting messages after they've been downloaded.

Hope I don't offend anyone by asking a getmail question on the procmail
list.  But, I use getmail to get messages over to procmail.  The problem I'm
having is that getmail keeps downloading the same messages over and over --
despite being told not to.  I can't get getmail to delete them after they're
downloaded.

Can anyone tell me what I'm doing wrong?

Here's my getmailrc

[options]
delete = true
read_all = false
message_log = ~/.getmail/log
message_log_verbose = true

[retriever]
type = SimplePOP3Retriever
server = mail.mxes.net
username = ruliap <at> tuffmail.com
password = xxx

[destination]
type = MDA_external
path = /usr/bin/procmail
Permalink | Reply | 0 comments |
headers
LuKreme | 22 Jan 2011 02:08
Favicon

Re: getmail not deleting messages after they've been downloaded.

On 21-Jan-2011, at 09:49, Richard Reina wrote:
> 
> Can anyone tell me what I'm doing wrong?

Not really, but problems like this often point to an issue with the mail server.

If getmail writes detailed logs (or can with the right flag) then take a look at them. I suspect what is
happening is getmail is telling your server to delete the messages and your server is not doing it.

--

-- 
The person on the other side was a young woman. Very obviously a young
woman. There was no possible way that she could have been mistaken for a
young man in any language, especially Braille.
Permalink | Reply | 0 comments |

Gmane