At 09:44 2002-02-26 -0500, peter(_at_)compclass(_dot_)com did say:
I understand from other responses that this puts the responsibility
on the sender but I don't have time to keep aggresively updating my
filters.
Then make use of one of the spam filter packages out there such as
SpamAssassin or similar. Just update it every so often. That's *FAR*
better than requiring other people to justify themselves to you.
You could retain a greenlisting system whereby any message which DOESN'T
match the greenlist is flagged (you just add a header, by running it
through formail - using the same syntax as was used to add the X-Loop:,
just simply adding something like "X-Uncertified:"). Then, messages come
in, and if they're not found in the greenlist, they get flagged. The user
can filter messages with this flag into a "suspect" folder on their mail
client, which they can glance at occassionally. If they spot a message
from a valid source, they can _FORWARD_ that message to a submission
address on the server (or change the subject and forward it to themselves),
which would process that message to add that individual (or list) to that
user's greenlist.
Prospective clients don't get slighted, you don't have to contend with mail
looping issues, and it's entirely voluntary on the part of the user.
Here's just a handful of the really BIG problems with a "prove to me that
you're a good guy" approach:
* if it is a small time spammer, and they're spewing from a valid
address, what if they DO respond? They're now inside your defences.
* A friend want to send a message to you, but can't hang around some
public access terminal -- they send the message, but it bogs up in
your "show me the money" script - either sending the request to an
account that they cannot access (some public libraries do this), or
sending it to their hotmail/whatever account - but they're off the PC
by that point. Net result: you don't get the message before they're
on the plane to Tahiti. Or the WTC.
* Some joker subscribes you or a customer of yours to a hundred
mailing
lists - many of which use a mechanism whereby you reply to the welcome
message which includes a codenumber string. Guess what? Your
"show me
the money" script handily does this - automatically confirming the
user's subscription on like 80 of those 100 lists (the other 20
probably don't use confirmations). Now you're stuck with manually
getting yourself off of those lists. Fun.
* You subscribe to a mailing list. It sends out a welcome message
instructing you how to confirm your subscription. Perhaps it is one
step removed from the standard "simply reply" type - but owing to
the volume of such messages, no sane admin would have the welcome
messages return to a human - so the autoreply will go to the ether -
OR bounce back to you with a help text (quite probably NOT including
your X-Loop), which your system will see as a new message and send
ANOTHER confirm to, thereby continuing the grand tradition of what we
like to call a mail loop.
It isn't just that fact that foisting your spam prevention measures off
onto other people is rude, it's that the approach is totally riddled with
faults. The above list is merely what springs _immediatley_ to mind -
there are more I'm sure.
This is an implementation that many of my clients have
requested and is why I am persuing an answer. My apologies if it
offends anyone. This is not my intention.
It gets offensive when someone (and they do, trust me) posts a question in
some forum, and everyone who takes THEIR TIME to freely respond to it ends
up having to respond to some "acknowledge you're not a spammer" process, it
becomes a big turnoff.
It's really bad when the response system doesn't obey Reply-To -- yet
equally bad when it DOES (because of some lists which actively define
Reply-To to the list address, or have users such as myself that direct the
replies to the list, necessitating a manual override on the part of the
respondant if they really want to send it offlist - NOBODY should be
sending autoreplies from accounts which they use to subscribe to lists -
but few people who discover that they can tell the whole world they're on
vacation for the next six months ever bother to think the process through).
When some user has a prospective client that emails them, and that prospect
gets a "prove to me that you're not a spammer" greeting, that could
contribute to ill will. I don't see provisions in your script to allow for
filtering entire domains as approved.
I bet it *REALLY* sucks when the client (or the client's assistant who
isn't _already_ in your greenlist) sends you a series of large attachments
for some project - and not only does the message go ignored at your end,
but the SMTM ("show me the money") script SENDS THEM THEIR *ENTIRE* MESSAGE
- ATTACHMENTS AND ALL, BUT NOW MANGLED - BACK TO THEM IN THE PROCESS!
Yea, I forsee someone making friends.
>Hopefully, you've pre-filtered this list, because I'm not about to jump
>through hoops so that you can accept an answer to your own question. I
>doubt I am alone in this thinking.
Yes. I have procmail processing several email lists and it works great.
If you're doing this for your _clients_, they'll need to know that they
should pre-filter lists before expecting that everyone on those lists is
going to respond. That means they'd hella better be ready to tweak their
filters the instant that they subscribe to a list, since subbing and
putting it off for a few hours could mean SCORES of pissed off list users,
who are now predisposed against your user because they're obviously a twit
for subbing to a list and expecting the people on that list to authenticate
themselves.
Of course, many lists are still a route for spam to arrive (including
rather ironically, the procmail list), so this method won't stop
list-bourne spam, so you're back at square one in that reguard.
>:0f
>| formail -A "X-Loop: myaddress"
I have added this and it gets tagged onto messages I return.
Good (though this additional header simply belongs in the formail -rk....
invocation that generated the reply - no need to invoke formail a separate
time, but I see that's what you are doing already below).
I haven't yet been able to get procmail to see this and accept the
message yet though. I'm obviously not writing the rule properly and
I hope someone can help me.
Time for you to enable VERBOSE logging and examine your log files and see
what procmail is doing as it passes through your filter.
:0:
* ^From: MAILER-DAEMON.*
/dev/null
That's laughable - you don't want to know when a message bounces? Of
course, this won't catch all such bounces - nor is this the ^MAILER_DAEMON
macro. Also, the trailing .* is superfluous, and the locking when writing
to /dev/null is wholly unnecessary.
:0
* !^FROM_DAEMON
* !^FROM +$MYNAME
There is no "^FROM" macro. See 'man procmail' for the macros that there
are. Perhaps you mean to use " * ! ^From:.*\<$MYNAME". Note that you also
don't excerpt what $MYNAME is set to, so from our perspective, we don't
know if it's an address, or a name comment.
* !^X-Loop: peter(_at_)compclass(_dot_)com
{
As a matter of style, the first line after the conditions end should be the
start of the delivery rule (or the opening brace). This still works, but
it doesn't follow the accepted style.
FROM=`formail -rx "To:"`
:0
* ? egrep $FROM $FRIEND_LIST
$DEFAULT
That looks like a malformed egrep request. Should be case insensitive
(-i), and you should really consider anchoring the search
expression: ^$FROM$ which would say "match only those lines where the
WHOLE text of that line is this address." Without these changes, you'd get
the following types of incorrect results:
$FROM in $FRIEND_LIST file boolean
bob(_at_)someisp(_dot_)net joebob(_at_)someisp(_dot_)net
true
BOB(_at_)someisp(_dot_)net bob(_at_)someisp(_dot_)net
false
bob(_at_)someisp(_dot_)co bob(_at_)someisp(_dot_)com
true
Because the header extraction that will take place with the formail
invocation you're using, there will be a leading SPACE on the data. Keep
in mind that it'll need to be in the file. That also means that where you
check for it, the variable needs to be in quotes, to preserve the space:
* ? egrep -i ^"$FROM"$ $FRIEND_LIST
:0
* $ Subject:.*$FILTER_PASSWD
{
:0c
$DEFAULT
:0
| echo $FROM >> $FRIEND_LIST
If you're outputting to a file, you should use LOCKING on that
recipe. Note also the leading space issue raised above, so this should be:
:0:
| echo "$FROM:" >> $FRIEND_LIST
This stuff REALLY came out of a book? Verbatim? Geez, ORA books usually
go through some decent technical editing before going to print. Of course,
one can wonder why this whole scheme was published in the first place,
given the problems inherent with the design, even despite the failures in
syntax.
:0
| (formail -rkA"Precedence: junk" \
-A"X-Loop: peter(_at_)compclass(_dot_)com" ; \
[message deleted for brevity]
FTR, the message can be included from a file using 'cat', which could make
it easier to manage the message text. Say because one user wants to
perform the appropriate grovelling for forgiveness for this affront, while
the next might choose a different tack.
) | $SENDMAIL -t && echo "Rejected mail from $FROM Re: $SUBJECT :
`date`" >> $HOME/procmail_log
This assumes the LOGFILE name. That's bad mojo - good design uses
VARIABLES for a reason. Why not use $LOGFILE instead of hardcoding the
logfile name here? Better yet, why not just use LOG= to assign the
text? Note that the `date` shouldn't be wholly necessary if you've
examined the procmail log before -- the delivery disposition information
which is also sent to the log contains the date information from the From_
line already (as well as the Subject: header):
From procmail-admin(_at_)Lists(_dot_)RWTH-Aachen(_dot_)DE Tue Feb 26 06:46:44
2002
Subject: Re: Looping problem
Folder: procmail.mbx 7537
>At the outter layer of your whole bounceback system, you'd add an INVERTED
>check for this X-Loop:
>
>* ! ^X-Loop: myaddress
I have this as above but I fear it is not in the correct place.
It looks to be in the correct place. Granted, messages found to have the
loop will pass through to you as if they'd be authorized, although the user
will not end up in your auth database - that'd at least allow you to
respond to *THEIR* ack system, say while resending your ack request so that
you can have them resend their message to you (though if they have the same
system at the other end, they've bounced back the original message they
send to you, which you bounced to them).
As long as the formail invocation you're using for the reply generation is
how this filter appeared in the book (i.e. is what the guy at the other end
is using), you should be good to go - the previous X-Loop header(s) will be
retained when the reply is generated. There isn't much more you can do if
you're going to resort to autoreplies.
Well, I guess you could adopt a vacation-esque address cache - add
addresses awaiting auth to a data base, and don't repetatively send them
requests to auth. You could purge the cache every so often. Given my
dislike for the overall SMTM approach, I hope you won't hold it against me
that I don't feel the urge to develope that code for you here...
I have experimented with putting it in different places but with no
succes. procmail still bounces the message unless the key word is
in the subject.
You really aught to try enabling verbose logging and see what shows up in
the log.
I am also curious if anyone knows how to specify the mbox format
that procmail should use. For example, I work with SCO Unix and it
writes messages into incoming mail files with the ^A^A^A^A message
Hmm, it's been about 15 years since I did anything with SCO. I can't help
you there.
---
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.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail