procmail recipe causing "bounced mail"?

I subscribe to a few high-volume mailing lists, in which I participate
actively. However, I'm often away from e-mail for weeks at a time
(such as the last three weeks). Since my ISP account is one with
limited diskspace, before such occasions I activate (i.e. uncomment)
procmail rules like

:0
* ^TO_mega_volume@firehydrant.org
/dev/null

This has worked well before, but I just received an automated
message from the mailing list I most recently joined saying that
messages to me have been "bouncing" (i.e. they are getting mail
from my host's MAIL-DAEMON and the subject line "Undelivered Mail
Returned to Sender"). I'm sure the reason has to do with the
procmail rule above, but I don't understand why.

Now, I know that there are many solutions to the problem of
temporarily turning off incoming mail from high-volume lists that
don't require fussing with procmail rules, but finding a solution
to this problem is *not* the reason I'm posting this.

What I want is to *correct* my understanding of what procmail is
actually doing. I thought that the rule above would simply discard
the mail addressed to the list, not cause anything to be sent back
("bounced") in response. Is there anything I can do to the recipe
above to ensure that procmail simply deletes the matching mail
"silently" and doesn't "bounce" anything to the sender?

My system is Unix (NetBSD), and the incantation in my .forward file is

"|IFS=' ';exec /usr/local/bin/procmail||exit 75 #kyle30439"

Thanks!

kj


--
NOTE: In my address everything before the first period is backwards;
and the last period, and everything after it, should be discarded.

Re: procmail recipe causing "bounced mail"?

On Sat, 1 Jan 2005 19:47:49 +0000 (UTC), kj
wrote:

> I subscribe to a few high-volume mailing lists, in which I
> participate actively. However, I'm often away from e-mail for
> weeks at a time (such as the last three weeks). Since my ISP
> account is one with limited diskspace, before such occasions I
> activate (i.e. uncomment) procmail rules like


>
>:0
> * ^TO_mega_volume@firehydrant.org
> /dev/null
>


> This has worked well before, but I just received an automated
> message from the mailing list I most recently joined saying
> that messages to me have been "bouncing" (i.e. they are
> getting mail from my host's MAIL-DAEMON and the subject line
> "Undelivered Mail Returned to Sender").

How come you can get mail from the listadmin but not the list?

> I'm sure the reason
> has to do with the procmail rule above, but I don't understand
> why.
>


No. It doesn't.

You REALLY need to read the procmail man pages.


> Now, I know that there are many solutions to the problem of
> temporarily turning off incoming mail from high-volume lists
> that don't require fussing with procmail rules, but finding a
> solution to this problem is *not* the reason I'm posting this.
>
> What I want is to *correct* my understanding of what procmail
> is actually doing. I thought that the rule above would simply
> discard the mail addressed to the list, not cause anything to
> be sent back ("bounced") in response.


That's exactly what it does.

Procmail can't cause your host's MTA to do anything.

If procmail has received the mail, then it wasn't bounced.

> Is there anything I can
> do to the recipe above to ensure that procmail simply deletes
> the matching mail "silently" and doesn't "bounce" anything to
> the sender?

Yes. Don't touch it.




AC

Re: procmail recipe causing "bounced mail"?

kj :
>
> I subscribe to a few high-volume mailing lists, in which I participate
> actively. However, I'm often away from e-mail for weeks at a time
> (such as the last three weeks). Since my ISP account is one with
> limited diskspace, before such occasions I activate (i.e. uncomment)
> procmail rules like
>
> :0
> * ^TO_mega_volume@firehydrant.org
> /dev/null

Why not just unsubscribe before you leave? As for procmail though:

VERBOSE=yes
:0
* ^TO_mega_volume@firehydrant.org
/dev/null
VERBOSE=no

will tell you what that's doing. Check your procmail log file.

Also, I see you have a leading space on lines 2 and 3 in your recipe
above. Could that be the problem?

Finally, there's lots of ways for people to post to lists, and they
may not all show that address. You might want to look at some of the
headers in them and find other distinguishing characteristics, such as
Newsgroups: lines, Delivered-To:, Received:, Posted-To:, & etc.

> My system is Unix (NetBSD), and the incantation in my .forward file is
>
> "|IFS=' ';exec /usr/local/bin/procmail||exit 75 #kyle30439"

..forward is specific to your MTA. man procmail mentions what your
..forward should look like for your MTA. Mine's exim, and my .forward
is:

|/usr/bin/procmail


--
Any technology distinguishable from magic is insufficiently advanced.
(*) http://www.spots.ab.ca/~keeling Linux Counter #80292
- - http://www.ietf.org/rfc/rfc1855.txt
Spammers! http://www.spots.ab.ca/~keeling/autospam.html

Re: procmail recipe causing "bounced mail"?

On 1 Jan 2005 22:22:32 GMT, s. keeling wrote:
> kj :
>
>> :0
>> * ^TO_mega_volume@firehydrant.org
>> /dev/null
>
> Also, I see you have a leading space on lines 2 and 3 in your recipe
> above. Could that be the problem?

No. Being an ol' "Procedure Progrmmer", I started out coding
my procmail recipes this-a-way. There's no problem in this area.

But, getting back to the OP's problem. Maybe the list email is
coming in 'different' -- from a different MTA -- from a different
domain -- or with totally different looking headers. I.e., maybe
something changed on the other end.

Too, maybe your ISP, in the never ending attempt to thwart spammers,
is now blocking in a manner that gets cross-wise with the email list
you are on. That happened with me at my ISP with a email re-director
service from an organization I belong to. My ISP opened a hole for
me WRT that incoming traffic.

HNY
Jonesy
--
| Marvin L Jones | jonz | W3DHJ | linux
| Gunnison, Colorado | @ | Jonesy | OS/2 __
| 7,703' -- 2,345m | config.com | DM68mn SK

Re: procmail recipe causing "bounced mail"?

Alan Connor wrote:
> On Sat, 1 Jan 2005 19:47:49 +0000 (UTC), kj
> wrote:
>
>
>>I subscribe to a few high-volume mailing lists, in which I
>>participate actively. However, I'm often away from e-mail for
>>weeks at a time (such as the last three weeks). Since my ISP
>>account is one with limited diskspace, before such occasions I
>>activate (i.e. uncomment) procmail rules like
>
>
>
>>:0
>>* ^TO_mega_volume@firehydrant.org
>>/dev/null
>>
>
>
>
>>This has worked well before, but I just received an automated
>>message from the mailing list I most recently joined saying
>>that messages to me have been "bouncing" (i.e. they are
>>getting mail from my host's MAIL-DAEMON and the subject line
>>"Undelivered Mail Returned to Sender").
>
>
> How come you can get mail from the listadmin but not the list?
>
>
>> I'm sure the reason
>>has to do with the procmail rule above, but I don't understand
>>why.
>>
>
>
>
> No. It doesn't.
>
> You REALLY need to read the procmail man pages.
>
>
>
>>Now, I know that there are many solutions to the problem of
>>temporarily turning off incoming mail from high-volume lists
>>that don't require fussing with procmail rules, but finding a
>>solution to this problem is *not* the reason I'm posting this.
>>
>>What I want is to *correct* my understanding of what procmail
>>is actually doing. I thought that the rule above would simply
>>discard the mail addressed to the list, not cause anything to
>>be sent back ("bounced") in response.
>
>
>
> That's exactly what it does.
>
> Procmail can't cause your host's MTA to do anything.
>
> If procmail has received the mail, then it wasn't bounced.
>
>
>> Is there anything I can
>>do to the recipe above to ensure that procmail simply deletes
>>the matching mail "silently" and doesn't "bounce" anything to
>>the sender?
>
>
> Yes. Don't touch it.
>
>
>
>
> AC
>
>

In Short Alan, the check is for the Message to be addressed to the list,
A notice from the admin is addressed to the recipient and not to the list.

AK

Re: procmail recipe causing "bounced mail"?

kj wrote:

> I subscribe to a few high-volume mailing lists, in which I participate
> actively. However, I'm often away from e-mail for weeks at a time
> (such as the last three weeks). Since my ISP account is one with
> limited diskspace, before such occasions I activate (i.e. uncomment)
> procmail rules like
>
> :0
> * ^TO_mega_volume@firehydrant.org
> /dev/null
>
> This has worked well before, but I just received an automated
> message from the mailing list I most recently joined saying that
> messages to me have been "bouncing" (i.e. they are getting mail
> from my host's MAIL-DAEMON and the subject line "Undelivered Mail
> Returned to Sender"). I'm sure the reason has to do with the
> procmail rule above, but I don't understand why.
>
> Now, I know that there are many solutions to the problem of
> temporarily turning off incoming mail from high-volume lists that
> don't require fussing with procmail rules, but finding a solution
> to this problem is *not* the reason I'm posting this.
>
> What I want is to *correct* my understanding of what procmail is
> actually doing. I thought that the rule above would simply discard
> the mail addressed to the list, not cause anything to be sent back
> ("bounced") in response. Is there anything I can do to the recipe
> above to ensure that procmail simply deletes the matching mail
> "silently" and doesn't "bounce" anything to the sender?
>
> My system is Unix (NetBSD), and the incantation in my .forward file is
>
> "|IFS=' ';exec /usr/local/bin/procmail||exit 75 #kyle30439"
>
> Thanks!
>
> kj
>
>

How certain are you that the rejection occurs during the procmail
process and not before?

I believe someone has responded that you should enable logging to
determine the source. Are you sure that other than the high volume
mailing lists, nothing could have pushed your account overquota? What
happens to messages when your account is overquota? Do they get rejected?

AK

Re: procmail recipe

felmon davis :
> On Thu, 31 Aug 2006 06:19:04 +0000, Paul Colquhoun wrote:
>
>
> > That will match as long as there is one character on the line that is
> > not in the set '.@;'.
> >
> > Have you tried:
> >
> > * ^from[^\.\@\-]*$
> >
> > That requires every character in the line (after the 'from') to be in
> > the set "not '.@;'"
>
> this doesn't seem to work. here is the relevant snippet:
>
> :0 B:
> * ^from[^\.\@\-]*$
> | formail -A "X-NewTest: Yes">> SuspectSpam
>
> procmail.log says 'No match on "^from[^\.\@\-]*$"'.

For the record, comp.mail.misc is the right place to post procmail
questions. Followups set.

I note you're not allowing for spaces after the "from", and you're
insisting that "from" be at the start of the line. Is it? Why not
post the relevant "from" line that you're attempting to match?


--
Any technology distinguishable from magic is insufficiently advanced.
(*) http://www.spots.ab.ca/~keeling Linux Counter #80292
- - http://www.faqs.org/rfcs/rfc1855.html Please, don't Cc: me.
Spammers! http://www.spots.ab.ca/~keeling/emails.html

Re: procmail recipe

s. keeling wrote:
> felmon davis :
>> On Thu, 31 Aug 2006 06:19:04 +0000, Paul Colquhoun wrote:
>>
>>
>>> That will match as long as there is one character on the line that is
>>> not in the set '.@;'.
>>>
>>> Have you tried:
>>>
>>> * ^from[^\.\@\-]*$
>>>
>>> That requires every character in the line (after the 'from') to be in
>>> the set "not '.@;'"
>> this doesn't seem to work. here is the relevant snippet:
>>
>> :0 B:

The "B" flag here is telling the recipe to egrep the body of the message
and ignore the headers. Leaving this flag off, or using an "H" flag will
have the recipe egrep the headers and ignore the body.

>> * ^from[^\.\@\-]*$
>> | formail -A "X-NewTest: Yes">> SuspectSpam
>>
>> procmail.log says 'No match on "^from[^\.\@\-]*$"'.
>
> For the record, comp.mail.misc is the right place to post procmail
> questions. Followups set.
>
> I note you're not allowing for spaces after the "from", and you're
> insisting that "from" be at the start of the line. Is it? Why not
> post the relevant "from" line that you're attempting to match?
>
>

--
Garen

Re: procmail recipe

On Sun, 03 Sep 2006 00:11:17 +0000, s. keeling wrote:

> For the record, comp.mail.misc is the right place to post procmail
> questions. Followups set.

thanks.

> I note you're not allowing for spaces after the "from", and you're
> insisting that "from" be at the start of the line. Is it? Why not
> post the relevant "from" line that you're attempting to match?

the 'from' will be at the start of the line. the example is 'from hell' -
a two-word phrase starting with 'from' separated from a 2nd word,

there needs to be a space after 'from' therefore. I am not sure how to
mark that.

Felmon

Re: procmail recipe

On Sun, 03 Sep 2006 01:16:58 -0600, Garen Erdoisa wrote:

>>> :0 B:
>
> The "B" flag here is telling the recipe to egrep the body of the message
> and ignore the headers. Leaving this flag off, or using an "H" flag will
> have the recipe egrep the headers and ignore the body.

I wanted the headers ignored.

some emails come through with 'from word' as part of the headers -
exactly like that but replace 'word' with some random single word.
these emails are all spam.

I have been trying to test my recipe but doing the testing on the 'from
word' construct in the body, easier for me to test it that way. once I
have the right recipe, I would apply it to the headers.

I would be happy to learn a better way!

Felmon

Re: procmail recipe

felmon davis wrote:

> On Sun, 03 Sep 2006 00:11:17 +0000, s. keeling wrote:
>
>
>>For the record, comp.mail.misc is the right place to post procmail
>>questions. Followups set.
>
>
> thanks.
>
>
>>I note you're not allowing for spaces after the "from", and you're
>>insisting that "from" be at the start of the line. Is it? Why not
>>post the relevant "from" line that you're attempting to match?
>
>
> the 'from' will be at the start of the line. the example is 'from hell' -
> a two-word phrase starting with 'from' separated from a 2nd word,
>
> there needs to be a space after 'from' therefore. I am not sure how to
> mark that.
>
> Felmon
>
>

you can test as follows for a two word line
:0
^ from[ ]*[a-z]+$
spam

AK

Re: procmail recipe

felmon davis wrote:
> On Sun, 03 Sep 2006 01:16:58 -0600, Garen Erdoisa wrote:
>
>>>> :0 B:
>> The "B" flag here is telling the recipe to egrep the body of the message
>> and ignore the headers. Leaving this flag off, or using an "H" flag will
>> have the recipe egrep the headers and ignore the body.
>
> I wanted the headers ignored.
>
> some emails come through with 'from word' as part of the headers -
> exactly like that but replace 'word' with some random single word.
> these emails are all spam.
>
> I have been trying to test my recipe but doing the testing on the 'from
> word' construct in the body, easier for me to test it that way. once I
> have the right recipe, I would apply it to the headers.
>
> I would be happy to learn a better way!
>
> Felmon
>

This is an example of how I construct procmail test recipes:

The advantage of this method is that it lets you test and fine tune
regular expressions or other procmail recipe parameters without having
to send any emails through your system.

---file /tmp/username/test.rc----

VERBOSE=yes

:0 H:
* ^()\/from[^\.\@\-]*$
| formail -A "X-NewTest: Yes">> /tmp/username/SuspectSpam

:0
/dev/null

---end of file---

---file /tmp/username/testmessage.txt ---
From: some_pattern
To: some_username@example.com

Some body text

---end of file---

Then to run your test recipe from the command line:

cd /tmp/username
cat testmessage.txt |procmail /tmp/username/test.rc

You can see the output directly on the terminal using this or a similar
method.

ie:

procmail: [20348] Sun Sep 3 17:34:20 2006
procmail: Assigning "MATCH="
procmail: Matched "From: some_pattern
"
procmail: Match on "^()\/from[^\.\@\-]*$"
procmail: Locking "/tmp/username/SuspectSpam.lock"
procmail: Executing " formail -A "X-NewTest: Yes">>
/tmp/scamper/SuspectSpam"
procmail: Assigning "LASTFOLDER= formail -A "X-NewTest: Yes">>
/tmp/username/SuspectSpam"
procmail: Unlocking "/tmp/username/SuspectSpam.lock"
Folder: formail -A "X-NewTest: Yes">> /tmp/username/SuspectSpam
66


If you use this method it's important not to forget to /dev/null by
default as the final part of your test recipe, else any such testing can
result in the test messages possibly being appended to a mailbox, or
some wierd filename in your home directory.

--
Garen

Re: procmail recipe

On Sun, 03 Sep 2006 17:55:32 -0600, Garen Erdoisa wrote:

>
> If you use this method it's important not to forget to /dev/null by
> default as the final part of your test recipe, else any such testing can
> result in the test messages possibly being appended to a mailbox, or
> some wierd filename in your home directory.

excellent! thank you for this tip, been needing it.

Felmon

[OT] s. keeling (was: re: procmail recipe)

On comp.mail.misc, in , "s. keeling" wrote:
> Path: text.usenetserver.com!atl-c01.usenetserver.com!news.usenetse rver.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giga news.com!nntp.giganews.com!cyclone1.gnilink.net!gnilink.net! newsfeed2.telusplanet.net!newsfeed.telus.net!edtnps89.POSTED !53ab2750!not-for-mail
> Newsgroups: comp.os.linux.misc,comp.mail.misc
> From: "s. keeling"

http://groups.google.com/advanced_group_search
s. keeling
Results 1 - 100 of 213 posts in the last year
1 ab.jobs
9 alt.comp.linux
12 alt.os.linux
5 alt.os.linux.debian
3 alt.os.linux.slackware
1 alt.tv.stargate-sg1
1 calgary.jobs
1 calgary.test
2 comp.mail.misc
14 comp.os.linux.misc
1 comp.os.linux.security
5 comp.os.linux.setup
1 comp.unix.misc
1 gnu.utils.help
7 linux.debian.bugs.dist
2 linux.debian.curiosa
29 linux.debian.user
2 mailing.database.myodbc
2 news.software.readers
1 rec.arts.sf.written

Someone using the latest slrn who posts on almost nothing but
technical groups and edits his own headers and is therefore a
very experienced Useneter, expects us to believe that he has only
posted 213 times in the last year?

Spammers sure are stupid (see below)


> Subject: Re: procmail recipe
> References:
> Reply-To: keeling@spots.ab.ca
> Followup-To: comp.mail.misc
> X-UCE: I forward UCE/spam with ALL headers to abuse@your.isp UNREAD!

No you don't. It's almost impossible to determine the
originating IP of spam.

If it wasn't, spam wouldn't be anywhere near the problem it is.

DUH <<<<
> X-UCE2: Wow, are spammers ever stoopid!

They sure are. Unlike anyone else on the Usenet, they make a
big point of hating spam.

> X-PGP-Key: GPG key: http://keyserver.noreply.org:11371/pks/lookup?op=vindex&sear ch=0x48EE77B1AC94E4B7

Takes 2 minutes to create a GPG/PGP key. They are worthless
unless they are _very_ carefully investigated.

There's no point in it unless you are part of his circle of trust
and in that case you should just ignore it. It means nothing.

He's counting on your ignorance.

> Message-ID:
> User-Agent: slrn/0.9.8.1 (Debian)
> Lines: 35
> Date: Sun, 03 Sep 2006 00:11:17 GMT
> NNTP-Posting-Host: 209.115.174.241

$ host 209.115.174.241
Name: dsl2.spots.ab.ca

Port State Service
22/tcp filtered ssh << secure remote login
25/tcp open smtp << mail server
53/tcp filtered domain << whois server (don't believe a word of it)
80/tcp open http
135/tcp filtered loc-srv
139/tcp filtered netbios-ssn
443/tcp open https << secure webserver
445/tcp filtered microsoft-ds
587/tcp open submission
12345/tcp filtered NetBus

That's about what I'd expect a spammer's computer to run.

> X-Trace: edtnps89 1157242277 209.115.174.241 (Sat, 02 Sep 2006 18:11:17 MDT)
> NNTP-Posting-Date: Sat, 02 Sep 2006 18:11:17 MDT
> Xref: usenetserver.com comp.os.linux.misc:551087 comp.mail.misc:160273
> X-Received-Date: Sat, 02 Sep 2006 20:11:17 EDT (text.usenetserver.com)