You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by Daniel Quinlan <qu...@pathname.com> on 2004/07/22 06:10:36 UTC
blowback procmail rule
If any of you have a problem with blowback (bounces from forged spam and
viruses), this procmail rule should pretty much solve it.
Unfortunately, it has to be customized for your MTA and MUA (on a
per-user basis), but it works really well for me. The idea is to match
pretty much all bounces and then exclude data from the body that should
be found in legitimate bounces; ones sent locally due to a real
SMTP-time bounce or ones sent after SMTP, but containing data that
likely indicates you sent it (focusing on headers likely to be sent in a
bounce report).
If the envelope sender isn't in Return-path, you'll need to use the
appropriate header.
------- start of cut text --------------
:0
* ^Return-path: \<(\>|mailer.?daemon)
* !^Received:.*REGEXP_THAT_MATCHES_SMTP_TIME_BOUNCE(S)
* !^Message-Id: REGEXP_FOR_YOUR_MESSAGE_ID_FORMAT(S)
* !^From: FROM_AS_SENT_BY_YOUR_MUA(S)
blowback.in
------- end ----------------------------
So, for example, I replace FROM_AS_SENT_BY_YOUR_MUA(S) with:
Daniel Quinlan <qu...@pathname.com>
since that's what I use.
--
Daniel Quinlan
http://www.pathname.com/~quinlan/
Re: blowback procmail rule
Posted by Sidney Markowitz <si...@sidney.com>.
Daniel Quinlan wrote:
> It was a Message-ID added by my MTA, so the bounce probably arrived
> without a Message-ID.
That's what I meant... So all the cases of a MsgID without a From were
the result of your putting the MTA MsgID in your exclusion list, i.e., a
mistake.
That means that you only have to check for all the From addresses that
you use, as checking for MsgID adds nothing.
-- sidney
Re: blowback procmail rule
Posted by Daniel Quinlan <qu...@pathname.com>.
Sidney Markowitz <si...@sidney.com> writes:
> Is the local sent Received: rule looking for bounces that resulted
> from an SMTP reject, so the message comes from your own mail server?
Yep.
> How did you end up with any real bounces that had your msgid without
> your from, or was that the result of the same error as the one FP?
It was a Message-ID added by my MTA, so the bounce probably arrived
without a Message-ID.
Daniel
--
Daniel Quinlan
http://www.pathname.com/~quinlan/
Re: blowback procmail rule
Posted by Sidney Markowitz <si...@sidney.com>.
Daniel Quinlan wrote:
> That might work a tad better, yep. The Return-path: rule is header-only
> as is the local sent Received: rule, but the others are body-only.
Is the local sent Received: rule looking for bounces that resulted from
an SMTP reject, so the message comes from your own mail server?
How did you end up with any real bounces that had your msgid without
your from, or was that the result of the same error as the one FP?
-- sidney
Re: blowback procmail rule
Posted by Daniel Quinlan <qu...@pathname.com>.
Sidney Markowitz <si...@sidney.com> writes:
> Don't you need to use the :0 HB in the rule, or even better do something
> with separate :0 and :0 B rules for those that are looking in the
> headers of the bounce message and those that are looking for your
> original mail inside the body?
That might work a tad better, yep. The Return-path: rule is header-only
as is the local sent Received: rule, but the others are body-only.
Justin's idea to use the IP address works too, but I did get a few false
positives for that exemption.
- I searched my ham and bounces for these Return-paths:
- <>
- <mailer.?daemon
- <postmaster
- <.*(virus|norton|amavis|symantec).*\@
- producing 787 messages for which looked for the following exemptions:
- locally received in header ("local")
- my From: header in body ("from")
- my Message-Id: in body ("msgid")
- my IP in body ("ip")
count exemptions verdict
638 none almost definitely blowback
51 ip from real bounces
24 local msgid real bounces
17 ip msgid real bounces
15 from local real bounces
12 local real bounces
9 ip from local real bounces
4 ip local msgid real bounces
4 ip from msgid real bounces
4 ip 2 real bounces, 2 blowback
3 ip from local msgid real bounces
3 from local msgid real bounces
2 from real bounces
1 msgid 1 blowback
count per each exemption:
ip 92
from 87
msgid 56
local 70
Hmmm... I accidentally added my MTA message-id format as an exemption,
producing that one "false positive" for msgid at the bottom.
--
Daniel Quinlan
http://www.pathname.com/~quinlan/
Re: blowback procmail rule
Posted by Sidney Markowitz <si...@sidney.com>.
Don't you need to use the :0 HB in the rule, or even better do something
with separate :0 and :0 B rules for those that are looking in the
headers of the bounce message and those that are looking for your
original mail inside the body?
Also, I seem to recall that when I tried this that some mail servers did
not include the entire original message or even all the original headers
in the bounceback message, but now experimenting I haven't reproduced
that. Does anyone else have any specific examples of a good bounce that
doesn't include the original headers in the body or does something
strange like BASE64 encodes it?
-- sidney
Re: blowback procmail rule
Posted by Daniel Quinlan <qu...@pathname.com>.
Tony Finch <do...@dotat.at> writes:
> On Thu, 22 Jul 2004, Daniel Quinlan wrote:
> >
> > These schemes already exist and have been discussed (and used by some
> > folks). I've tried it myself. The problem is many mailing lists doing
> > sender verification barf all over it ... like this one.
>
> Yes :-( I'm working on a system which uses fixed envelope addresses for
> those particular problem recipient addresses, and variable ones for
> everyone else. I'm hoping that it will be easy enough for the average
> user, though they'll have to frob their mailing list subscriptions a bit
> when they turn the feature on.
Yeah, from my perspective, that's less optimal since you have to keep
updating it over time. Using VERP would be optimal if not for programs
doing sender verification on MAIL FROM (which I think is broken).
Daniel
--
Daniel Quinlan
http://www.pathname.com/~quinlan/
Re: blowback procmail rule
Posted by Tony Finch <do...@dotat.at>.
On Thu, 22 Jul 2004, Daniel Quinlan wrote:
>
> These schemes already exist and have been discussed (and used by some
> folks). I've tried it myself. The problem is many mailing lists doing
> sender verification barf all over it ... like this one.
Yes :-( I'm working on a system which uses fixed envelope addresses for
those particular problem recipient addresses, and variable ones for
everyone else. I'm hoping that it will be easy enough for the average
user, though they'll have to frob their mailing list subscriptions a bit
when they turn the feature on.
Tony.
--
f.a.n.finch <do...@dotat.at> http://dotat.at/
DOVER WIGHT PORTLAND PLYMOUTH: VARIABLE BECOMING WESTERLY 3 OR 4. THUNDERY
SHOWERS IN EAST. MODERATE OR GOOD WITH FOG PATCHES DEVELOPING FOR A TIME.
Re: blowback procmail rule
Posted by Daniel Quinlan <qu...@pathname.com>.
Tony Finch <do...@dotat.at> writes:
> I'm currently working on a scheme for cryptographically signing
> envelope return paths to protect against forgery in general, and
> collateral spam etc. as a consequence.
These schemes already exist and have been discussed (and used by some
folks). I've tried it myself. The problem is many mailing lists doing
sender verification barf all over it ... like this one.
That being said, I'm a fan of the idea.
Daniel
--
Daniel Quinlan
http://www.pathname.com/~quinlan/
Re: blowback procmail rule
Posted by Tony Finch <do...@dotat.at>.
On Thu, 22 Jul 2004, Daniel Quinlan wrote:
>
> As far as I can tell, vacation notices aren't sent with an envelope
> sender of <> or mailer-daemon, they're sent as the user.
Depends a lot on the software that creates them. Exim uses <> to protect
against loops.
I'm currently working on a scheme for cryptographically signing envelope
return paths to protect against forgery in general, and collateral spam
etc. as a consequence.
Tony.
--
f.a.n.finch <do...@dotat.at> http://dotat.at/
DOGGER FISHER GERMAN BIGHT: SOUTHEASTERLY 3 OR 4, OCCASIONALLY 5, VEERING
WESTERLY 4 OR 5 IN DOGGER LATER. SHOWERS. MODERATE OR GOOD WITH FOG PATCHES,
MAINLY IN WEST.
Re: blowback procmail rule
Posted by Daniel Quinlan <qu...@pathname.com>.
Tony Finch <do...@dotat.at> writes:
> Your rule will mis-classify vacation notices as blowback, because they
> do not contain your message ID in the way that bounces do.
lol - seems more like a feature ... if that were true
As far as I can tell, vacation notices aren't sent with an envelope
sender of <> or mailer-daemon, they're sent as the user.
Daniel
--
Daniel Quinlan
http://www.pathname.com/~quinlan/
Re: blowback procmail rule
Posted by Tony Finch <do...@dotat.at>.
On Wed, 21 Jul 2004, Daniel Quinlan wrote:
> If any of you have a problem with blowback (bounces from forged spam and
> viruses), this procmail rule should pretty much solve it.
Your rule will mis-classify vacation notices as blowback, because they do
not contain your message ID in the way that bounces do.
Tony.
--
f.a.n.finch <do...@dotat.at> http://dotat.at/
RATTRAY HEAD TO BERWICK ON TWEED: SOUTH 3 OR 4, OCCASIONALLY 5 IN NORTH,
VEERING SOUTHWEST IN SOUTH LATER. MAINLY FAIR, OUTBREAKS OF RAIN SPREADING
EAST LATER. MODERATE OR GOOD. SLIGHT, BUT MODERATE AROUND RATTRAY HEAD AT
FIRST.