headers
Dallman Ross | 1 Oct 2006 01:52

Re: Running a script from procmail

On Sat, Sep 30, 2006 at 01:56:46PM -0700, Professional Software
Engineering wrote:

> REALLY simplify and speed things up (since you're making use of fewer 
> processes):
> 
> :0:
> * ^X-Original-To:[      ]*\/[^  ]* <at> mydomain\.tld
> * MATCH ?? ^\/[^ <at> ]+
> * $? fgrep -x -i "$MATCH" $RCPT_BLACKLIST
> blacklist

> Note that I started composing this before I saw Dallman's
> most recent contribution (which also suggests eliminating the
> formail/awk).  This remains an improvement over his very similar
> method because there's no need to pipe the match string from echo
> into formail, and this also brings in the outer domain condition.
> Short of setting RCPT_BLACKLIST, the recipe above is the ENTIRETY
> of the recipe you need.

What pipe to formail?  I had this:

    :0
    * ^X-Original-To: \/[^ <at> ]+
    * $? echo $MATCH | fgrep -i -x -f $RCPT_BLACKLIST
    blacklist

(I should have used a lockfile.)

Okay, you mean pipe to fgrep instead of just running fgrep.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ruud H.G. van Tol | 1 Oct 2006 10:41
Picon

Re: Running a script from procmail

Professional Software Engineering schreef:
> Ruud H.G. van Tol:

>> It is generally not added, but my ISP adds a single "Envelope-To"
>> header field that contains all the aliases that the message is sent
>> to (aliases of the popbox concerned).
>
> Er, would that include those who received it via BCC?

Of course. Those "(aliases of the popbox concerned)" are the aliases
that are yours (limited per popbox).

So if a single multi-recipient message would arrive in two of your
popboxes, they have completely different Envelope-To: header fields,
each containing one or more adresses.
In other words, addresses of the Envelope-To: header field in one
copy(1) of the message never(2) occur in the Envelope-To: header field
of any of the other copies of the message. Again: of course.

(1) Physical copies are not necessary. There can still physically be
just a single copy of the message, and one or more sets of account
dependent header fields.

(2) A user can delete an alias and reuse the name to create a popbox,
but the old configuration should be used for the queued mail of that
moment.

--

-- 
Groet, Ruud
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steve A | 2 Oct 2006 20:29

Help with filtering the sender

Because some plonker is using my domain as a return-path when sending 
their spam, _I_ get a legitimate message from the intended recipient 
telling my I've sent a spam.

As most of these messages are from "postmaster" or "Mailer-Daemon" or 
similar, I intend to drop messages depending on the sender, but only if 
the message is not for a whitelisted recipient of my domain.

The part I need help with is what and how to match the sender.  For 
example, I have this variation in some of my already blocked messages:

(Envelope From)
 From MAILER-DAEMON  Sun Oct  1 16:39:40 2006
from ip-195-14-188-161.bnk.lt [195.14.188.161]
from batidos de mango to crabcakes. They can meet artists and artisans
 From dezeekant-tex <at> dezeekant-tex.com  Sun Oct  1 22:34:40 2006

(Message From:)
From: Mail Delivery System <Mailer-Daemon <at> yourhostingaccount.com>
From: Mail Delivery Service <postmaster <at> cluster.t-systems.com.br>
From: MAILER-DAEMON <>
From: "Internet Mail Delivery" <postmaster <at> us.army.mil>
From: Mail Delivery System <Mailer-Daemon <at> casiquiare.dattaweb.com>
From: E-mail Firewall <postmaster <at> fhda.edu>

 From these examples, which header should I match on (or is there 
another more reliable header)?  As I would need to match on (eg.) 
'postmaster' wherever it may appear in the header, should I be matching 
the entire header and use fgrep?
(Continue reading)

Permalink | Reply | 8 comments |
headers
Professional Software Engineering | 2 Oct 2006 21:17

Re: Help with filtering the sender

At 19:29 2006-10-02 +0100, Steve A wrote:
>Because some plonker is using my domain as a return-path when sending
>their spam,

If they're valid email addresses at your domain, this is referred to as 
"joe-jobbing".  Otherwise, it's simple forgery.

>_I_ get a legitimate message from the intended recipient telling my I've 
>sent a spam.

Dealing with this is best handled at the MTA, rather than receiving all the 
junk.

Write up a report about the problem (including "examine the message headers 
for submission IP address and you'll see that it didn't originate from 
here"), then configure your MTA to bounce messages delivered to the 
addresses getting the messages, including that URL.  Leave it in place for 
a few days, then lift it.  The webpage can include reference to an 
alternate address to use to send actual email to the original address.

If it's to your regular email address, that truely sucks.  There's going to 
be a LOT of different submission addresses - particularly from the 
microsoft crowd, where no two sites can simply send administrative bounces 
from a recognized address (heck, some send them from fake addresses).

I believe you could set the actual recipient address up to be an alias to 
two separate local accounts - one would generate an error to the sender, 
and the other would deliver as normal.  This way, your MTA could still deal 
with notifying irate senders, and any of your regular mail would still 
arrive (along with all the irate messages).  This approach has its issues
(Continue reading)

Permalink | Reply | 7 comments |
headers
Steve A | 2 Oct 2006 22:10

Re: Help with filtering the sender

Professional Software Engineering wrote:
> If they're valid email addresses at your domain, this is referred to
> as "joe-jobbing".  Otherwise, it's simple forgery.

They're valid addresses at my domain because I accept them because I 
haven't yet compiled a list of all the addresses I've used for myself 
(eg. procmail <at> mydomain.tld).  They're random (often rude) words used to 
make the user part of the address.

> Dealing with this is best handled at the MTA, rather than receiving
> all the junk.

I don't have control at SMTP level, only what procmail can do for me.

> Write up a report about the problem (including "examine the message
> headers for submission IP address and you'll see that it didn't
> originate from here"), then configure your MTA to bounce messages
> delivered to the addresses getting the messages, including that URL.
> Leave it in place for a few days, then lift it.  The webpage can
> include reference to an alternate address to use to send actual email
> to the original address.

I have big issues with bouncing messages of this nature, because it only 
adds to the pleathora of junk already in circulation, and I don't want 
to dump my problem onto someone else.

> If it's to your regular email address, that truely sucks.  There's

Yup, that's my problem.  I'm getting on average 2,500+ per day, most of 
which I can filter but I'm looking to tweak procmail so I can easily
(Continue reading)

Permalink | Reply | 6 comments |
headers
Google Kreme | 3 Oct 2006 00:24
Picon

Re: Help with filtering the sender

On 02 Oct 2006, at 14:10 , Steve A wrote:
> Professional Software Engineering wrote:
>> If they're valid email addresses at your domain, this is referred to
>> as "joe-jobbing".  Otherwise, it's simple forgery.
>
> They're valid addresses at my domain because I accept them because I
> haven't yet compiled a list of all the addresses I've used for myself
> (eg. procmail <at> mydomain.tld).  They're random (often rude) words  
> used to
> make the user part of the address.

So you have a wildcard on your domain to accept any * <at> yourdomain.tld?

This is why you don't do that.

Setup your mailserver to ONLY accept mail for real and valid  
accounts.  You can do most of this in /etc/postfix/virtual (or  
whatever) like this:

amazon <at> mydomain.tld  myemail+amazon <at> mydomain.tld
procmail <at> mydomain.tld myemail+procmail <at> mydomain.tld
etc.

You don't have to use plus addressing, of course, but it can make  
this super convenient.

Then setup your mailserver to rejevet unknown recipients.

You should never accept wildcard usernames, it's just an invitation  
to be DOSed with Spam.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Professional Software Engineering | 3 Oct 2006 00:29

Re: Help with filtering the sender

At 21:10 2006-10-02 +0100, Steve A wrote:
>Professional Software Engineering wrote:
> > If they're valid email addresses at your domain, this is referred to
> > as "joe-jobbing".  Otherwise, it's simple forgery.
>
>They're valid addresses at my domain because I accept them because I
>haven't yet compiled a list of all the addresses I've used for myself
>(eg. procmail <at> mydomain.tld).  They're random (often rude) words used to
>make the user part of the address.

IOW, you're accepting mail at your domain with a wildcard.  This isn't 
wise, since spammers don't have to have a valid email address in order to 
smack you.

If you have your email saved, grep it all for addresses:

grep " <at> rowyerboat\.com" | sed -e "s/^\(.*[ 
<]\)\([-a-z0-9_.+]* <at> rowyerboat\.com\)\(.*\)$/\2/i" | sort | uniq

(paren escapes are present because my shell needs them).  This could stand 
to be improved, but should serve well enough as a start point for you.

Sort though the list and delete the bogus ones, then bring the rest into 
your MTA config (for sendmail, you'd be replacing the wildcard in 
virtusertable with the list).  tweaking the above sed replacement text from:

         \2
to
         \2  yourlocaladdr
(Continue reading)

Permalink | Reply | 0 comments |
headers
Professional Software Engineering | 3 Oct 2006 02:15

Re: Help with filtering the sender

At 16:24 2006-10-02 -0600, Google Kreme wrote:
>Setup your mailserver to ONLY accept mail for real and valid
>accounts.  You can do most of this in /etc/postfix/virtual (or
>whatever) like this:
>
>amazon <at> mydomain.tld  myemail+amazon <at> mydomain.tld
>procmail <at> mydomain.tld myemail+procmail <at> mydomain.tld
>etc.

Of course, just using plussing right off helps shed spam and 
viruses.  Seems a fair number of address harvesters don't grok + as a 
legitimate email address component, and so they parse the RHS of the 
plussed address (when moving outwards from the  <at>  symbol they often anchor on):

myemail+procmail <at> mydomain.tld

is very likely to be harvested as procmail <at> mydomain.tld.  If you don't HAVE 
a procmail <at> mydomain.tld (and don't foolishly use wildcarding), then mail 
sent to the improperly parsed address will fail to deliver.

> > I don't have control at SMTP level, only what procmail can do for me.
>
>Then move your domain to a better ISP.  If you can't reject mail for
>unknown accounts then you're going ot be totally, completely, and
>most importantly, repeatedly fucked.

Heck, it's in the ISP's best interests to reduce the flow of spam through 
their servers, since it's wasted bandwidth, processor power, and disk 
space.  Of course, there are those who figure if you have a disk space 
quota, if it happens to fill up and you go to an overlimit charge, that's
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ruud H.G. van Tol | 3 Oct 2006 12:53
Picon

Re: Help with filtering the sender

Professional Software Engineering schreef:

> just using plussing right off helps shed spam and
> viruses.  Seems a fair number of address harvesters don't grok + as a
> legitimate email address component, and so they parse the RHS of the
> plussed address

Yes, so it's a big pity (pain in the yonder;) that so many websites
reject plussed addresses. Most of these websites are probably called
MySomething, but I hit the problem too on developers sites like that of
Nokia. "Invalid character in email address." and such. I always complain
back about it, but hardly ever get a proper reply.

--

-- 
Groet, Ruud
Permalink | Reply | 2 comments |
headers
Zbigniew Szalbot | 3 Oct 2006 16:20

beginner's question

Dear list members,

Beg your patience with me. I am willing and trying to learn but these are 
my first steps with procmail under FreeBSD 6.1. I have put the following 
in the .forward file:

"|exec /usr/local/bin/procmail || exit 75"

And I get this error when I try to send mail to a user where procmail 
should do some action:

2006-10-03 14:51:03 1GUjji-0008lE-Oc ** |exec /usr/local/bin/procmail || 
exit 75 <ADDRESS_GOES_HERE> R=userforward 
T=address_pipe_local: 
"exec" command not found for address_pipe_local transport

Perhaps I should also add that I use exim 4.63.

What I first want to accomplish, is properly generating a simply text 
email that will be send to a sender if a specific subject line "send 
eng-lcw-welcome" is matched.

Currently I am stuck with the error and not sure what to do. Thank you for 
your patience with me!

--
Zbigniew Szalbot
Permalink | Reply | 4 comments |

Gmane