You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Ole Nomann Thomsen <on...@uni-c.dk> on 2006/08/14 11:44:33 UTC
Using SA to prevent bouncing spam?
Hi, in order to avoid bouncing spam back to the (almost certainly) faked
sender-addresses, I thought I could use SA directly:
Suppose I configure it to substitute "<>" for the sender/reply-to in any
spam? That way spam-generated bounces would be dumped. Unfortunately It
doesn't seem possible:
* "rewrite_header from" will let met insert rfc 2822 comments but not
substitute entirely.
* "remove_header" and "add_header" will only let me work on "X-spam-*"
headers.
So am I left with writing my own wrapper here? That means a lot of testing
and double-testing, as I don't feel particularly lucky today.
- Ole.
Re: Using SA to prevent bouncing spam?
Posted by John Andersen <js...@pen.homeip.net>.
On Monday 14 August 2006 01:44, Ole Nomann Thomsen wrote:
> Hi, in order to avoid bouncing spam back to the (almost certainly) faked
> sender-addresses, I thought I could use SA directly:
Why would you bounce spam, with or without spamassassin?
That is a MTA setting, and every MTA in existence today recommends you
NOT bounce either spam or viri.
--
_____________________________________
John Andersen
Re: Using SA to prevent bouncing spam?
Posted by Ole Nomann Thomsen <on...@uni-c.dk>.
Ole Nomann Thomsen wrote:
> Hi, in order to avoid bouncing spam back to the (almost certainly) faked
> sender-addresses, I thought I could use SA directly:
Thanks for all your input. Using you replies, I managed to persuade the FC
guys to start providing me with a complete list of valid FC adresses.
I will now soon be able to use static goodrcptto lists or somesuch.
- Ole.
Re: Using SA to prevent bouncing spam?
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Mon, 14 Aug 2006, Ole Nomann Thomsen wrote:
> Hi, in order to avoid bouncing spam back to the (almost certainly) faked
> sender-addresses, I thought I could use SA directly:
>
> Suppose I configure it to substitute "<>" for the sender/reply-to in any
> spam? That way spam-generated bounces would be dumped. Unfortunately It
> doesn't seem possible:
>
> * "rewrite_header from" will let met insert rfc 2822 comments but not
> substitute entirely.
>
> * "remove_header" and "add_header" will only let me work on "X-spam-*"
> headers.
>
> So am I left with writing my own wrapper here? That means a lot of testing
> and double-testing, as I don't feel particularly lucky today.
>
> - Ole.
Other people have already commented on the issue of bouncing spam.
One detail that I think you don't understand, mail routing is controlled
by the envelope-sender and envelope-recipient addresses, the addresses
in the headers are ignored for that purposes. In most configurations SA
only gets to see/change the headers, it does not get to mess with the
envelope addresses at all.
Thus even if you could get SA to change the header addresses it wouldn't
have your desired effect.
Only your MTA gets to play with the envelope addresses, so any re-routing
you want to to will have to be done at the MTA level.
You need to look at something like mailscanner or amvis-new which
integrate into your MTA.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Using SA to prevent bouncing spam?
Posted by Duncan Hill <sa...@nacnud.force9.co.uk>.
On Tuesday 15 August 2006 10:46, Ole Nomann Thomsen wrote:
> I run a qmail frontend for a FirstClass system. The qmail accepts mail for
> about 500 domains, hosted on the FirstClass system, and scans them with SA.
> In then injects them into FirstClass. If the domain is known, but the user
> is
> wrong (as in "non-existing-user@gooddomain.org") the mail is rejected on
> smtp-level by FirstClass. Qmail then generates a bounce back to the
> original
> sender. In case of spam, origninal sender is faked and we have backscatter.
Consider switching to qpsmtpd instead of qmail-smtpd, and use a real-time
recipient verification tool, instead of living with QMail's 'accept
everything, then bounce' methods. Or a plugin that can read a static list of
valid users exported from FirstClass.
Re: Using SA to prevent bouncing spam?
Posted by Duncan Hill <sa...@nacnud.force9.co.uk>.
On Tuesday 15 August 2006 11:28, Ole Nomann Thomsen wrote:
> Yeah, that is pretty neat. But the Firstclass system is running at 99%
> capacity on the E-mail injection too. I mean, we are really pumping it in,
> trying to level the peak-priod and everything.
>
> Performing callouts will probably cause it to emit strange noises and
> smoke.
Static goodrcptto lists are what you need then - assuming your FC user list
doesn't change very often, you could do a nightly export from FC to
flatfile/hashed file and feed that file to qmail. At that point though,
we're beyond SA, and off topic :)
Re: Using SA to prevent bouncing spam?
Posted by DAve <da...@pixelhammer.com>.
Andreas Pettersson wrote:
> Ole Nomann Thomsen wrote:
>
>> I run a qmail frontend for a FirstClass system. The qmail accepts mail
>> for
>> about 500 domains, hosted on the FirstClass system, and scans them
>> with SA.
>> In then injects them into FirstClass. If the domain is known, but the
>> user is
>> wrong (as in "non-existing-user@gooddomain.org") the mail is rejected on
>> smtp-level by FirstClass. Qmail then generates a bounce back to the
>> original
>> sender. In case of spam, origninal sender is faked and we have
>> backscatter.
>>
>> I know qmail-ldap could be of some use here, but I have no way of setting
>> up an ldap-server that knows legitimate FirstClass adressess
>> (FirstClass itself
>> could do it, but it is running at 99% capacity most of the time, so no
>> go.
>> Exporting adresses from FirstClass won't do either, as there are
>> forum-adresses
>> that wont export). This is a classic "MTA frontend" problem, but I'm
>> afraid I'm
>> stuck with it.
>
>
> While I don't really see why ldap isn't an option, even with an 99%
> load, callout might be the solution.
> However, I don't run qmail but here's how it works with exim
>
> http://www.exim.org/exim-html-4.62/doc/html/spec_html/ch39.html#SECTcallver
>
>
> hälsningar,
> Andreas
chkuser for qmail, think 'Milter-Ahead' on steroids.
http://www.interazioni.it/opensource/chkuser/
If you want to check a static list of users, try validrcptto,
http://qmail.jms1.net/patches/validrcptto.cdb.shtml
I use both, they work great, using SA to stop the backscatter after the
fact is not the best way to go about this. I wouldn't worry about the
high load on your FirstClass system, stop the spam from getting past the
qmail server and your load will likely drop considerably. If you get as
much spam as we do anyway ;^)
DAve
--
Three years now I've asked Google why they don't have a
logo change for Memorial Day. Why do they choose to do logos
for other non-international holidays, but nothing for
Veterans?
Maybe they forgot who made that choice possible.
Re: Using SA to prevent bouncing spam?
Posted by Ole Nomann Thomsen <on...@uni-c.dk>.
Andreas Pettersson wrote:
> Ole Nomann Thomsen wrote:
>> Performing callouts will probably cause it to emit strange noises and
>> smoke.
>
>
> Why would it?
> It would generate the same amount of connect attempts to FC as it
> already does today, but the spam gets rejected instead of accepted and
> then bounced.
No, see, the problem is nondeliverable spam (NDS). Consider the setup:
Net -(1)-> [my box] -(2)-> [FC]
At present, I receive everything at (1) and then NDS gets rejected at (2),
generating a bounce. That's one connection to the overworked FC per NDS.
Using callouts, every NDS causes one callout at (2) and then gets rejected
at (1). The load at (2) must be about the same.
But then comes the deliverable spam and ham: They will now generate a
callout at (2), be accepted at (1) and then delivered at (2).
The total difference would the be one additional "VRFY" or "RCPT TO" (ot
whatever callout uses) at (2) per deliverable message, wouldn't it? This is
to much for FC. (But the bounce problem would be solved, I guess).
Re: Using SA to prevent bouncing spam?
Posted by Andreas Pettersson <an...@telia.com>.
Ole Nomann Thomsen wrote:
> Den 15.08.2006 kl. 12:01 skrev Andreas Pettersson <an...@telia.com>:
>
>> While I don't really see why ldap isn't an option, even with an 99%
>> load, callout might be the solution.
>> However, I don't run qmail but here's how it works with exim
>>
>> http://www.exim.org/exim-html-4.62/doc/html/spec_html/ch39.html#SECTcallver
>>
>
>
> Yeah, that is pretty neat. But the Firstclass system is running at 99%
> capacity on the E-mail injection too. I mean, we are really pumping it
> in,
> trying to level the peak-priod and everything.
>
> Performing callouts will probably cause it to emit strange noises and
> smoke.
Why would it?
It would generate the same amount of connect attempts to FC as it
already does today, but the spam gets rejected instead of accepted and
then bounced.
Regards,
Andreas
Re: Using SA to prevent bouncing spam?
Posted by Bookworm <qm...@bkwm.com>.
Ole Nomann Thomsen wrote:
> Den 15.08.2006 kl. 12:01 skrev Andreas Pettersson <an...@telia.com>:
>
>> While I don't really see why ldap isn't an option, even with an 99%
>> load, callout might be the solution.
>> However, I don't run qmail but here's how it works with exim
>>
>> http://www.exim.org/exim-html-4.62/doc/html/spec_html/ch39.html#SECTcallver
>>
>
> Yeah, that is pretty neat. But the Firstclass system is running at 99%
> capacity on the E-mail injection too. I mean, we are really pumping it
> in,
> trying to level the peak-priod and everything.
>
> Performing callouts will probably cause it to emit strange noises and
> smoke.
If your usernames don't change a lot, there's a validrcptto patch that
seems to work quite well.
John Simpson - http://www.jms1.net - has some good information on this
(don't use IE to go there)
I'm using a modified QmailRocks installation (modified because I helped
with the Slackware writeup for QMR). I'm modifying further to try to
squeeze better performance out of spamassassin and daemonizing.
BW
Re: Using SA to prevent bouncing spam?
Posted by Ole Nomann Thomsen <on...@uni-c.dk>.
Den 15.08.2006 kl. 12:01 skrev Andreas Pettersson <an...@telia.com>:
> While I don't really see why ldap isn't an option, even with an 99%
> load, callout might be the solution.
> However, I don't run qmail but here's how it works with exim
>
> http://www.exim.org/exim-html-4.62/doc/html/spec_html/ch39.html#SECTcallver
Yeah, that is pretty neat. But the Firstclass system is running at 99%
capacity on the E-mail injection too. I mean, we are really pumping it in,
trying to level the peak-priod and everything.
Performing callouts will probably cause it to emit strange noises and
smoke.
Re: Using SA to prevent bouncing spam?
Posted by Andreas Pettersson <an...@telia.com>.
Ole Nomann Thomsen wrote:
> I run a qmail frontend for a FirstClass system. The qmail accepts mail
> for
> about 500 domains, hosted on the FirstClass system, and scans them
> with SA.
> In then injects them into FirstClass. If the domain is known, but the
> user is
> wrong (as in "non-existing-user@gooddomain.org") the mail is rejected on
> smtp-level by FirstClass. Qmail then generates a bounce back to the
> original
> sender. In case of spam, origninal sender is faked and we have
> backscatter.
>
> I know qmail-ldap could be of some use here, but I have no way of setting
> up an ldap-server that knows legitimate FirstClass adressess
> (FirstClass itself
> could do it, but it is running at 99% capacity most of the time, so no
> go.
> Exporting adresses from FirstClass won't do either, as there are
> forum-adresses
> that wont export). This is a classic "MTA frontend" problem, but I'm
> afraid I'm
> stuck with it.
While I don't really see why ldap isn't an option, even with an 99%
load, callout might be the solution.
However, I don't run qmail but here's how it works with exim
http://www.exim.org/exim-html-4.62/doc/html/spec_html/ch39.html#SECTcallver
hälsningar,
Andreas
Re: Using SA to prevent bouncing spam?
Posted by Ole Nomann Thomsen <on...@uni-c.dk>.
Den 14.08.2006 kl. 19:48 skrev Sanford Whiteman
<sw...@cypressintegrated.com>:
>> Hi, in order to avoid bouncing spam back to the (almost certainly) faked
>> sender-addresses, I thought I could use SA directly:
>
> What's your MTA and/or SA-invoking app? Surely it is easier to have
> that agent parse SA's feedback (headers, subject mod or score) in
> deciding the final disposition of the msg than to try to trick the MTA
> into dumping the mail.
I use Qmail. To obtain the above, I must patch with spam-control or
similiar.
I'd rather do something simpler.
> Please elaborate on the use case in which you can't use MTA processing
> rules to prevent backscatter, given that you trust SA markup
> completely here, right?
I realize that I did not explain my setup sufficiently in the original
post:
I run a qmail frontend for a FirstClass system. The qmail accepts mail for
about 500 domains, hosted on the FirstClass system, and scans them with SA.
In then injects them into FirstClass. If the domain is known, but the user
is
wrong (as in "non-existing-user@gooddomain.org") the mail is rejected on
smtp-level by FirstClass. Qmail then generates a bounce back to the
original
sender. In case of spam, origninal sender is faked and we have backscatter.
I know qmail-ldap could be of some use here, but I have no way of setting
up an ldap-server that knows legitimate FirstClass adressess (FirstClass
itself
could do it, but it is running at 99% capacity most of the time, so no go.
Exporting adresses from FirstClass won't do either, as there are
forum-adresses
that wont export). This is a classic "MTA frontend" problem, but I'm
afraid I'm
stuck with it.
I trust SA enough, that I would suppress all bounces generated by
undeliverable
mails that SA believes to be spam. I though that if spamassassin wold
insert
"Reply-to: <>" in any spam message, this would do the trick.
It turns out I misread http://cr.yp.to/proto/mailloops.txt, confusing
"replier" and "bouncer". A replier will use "Reply-To:" before
envelope-sender
but a bouncer will not.
Den 15.08.2006 kl. 03:56 skrev John Andersen <js...@pen.homeip.net>:
> On Monday 14 August 2006 01:44, Ole Nomann Thomsen wrote:
>> Hi, in order to avoid bouncing spam back to the (almost certainly) faked
>> sender-addresses, I thought I could use SA directly:
>
> Why would you bounce spam, with or without spamassassin?
My original post wasn't clear: I *don't* want to bounce spam. And I dont
want
undeliverable spam to generate bounces. The question was (or should have
been)
how to avoid the latter in a simple way.
Den 15.08.2006 kl. 04:21 skrev David B Funk <db...@engineering.uiowa.edu>:
> Other people have already commented on the issue of bouncing spam.
>
> One detail that I think you don't understand, mail routing is controlled
> by the envelope-sender and envelope-recipient addresses, the addresses
> in the headers are ignored for that purposes. In most configurations SA
> only gets to see/change the headers, it does not get to mess with the
> envelope addresses at all.
> Thus even if you could get SA to change the header addresses it wouldn't
> have your desired effect.
You're absolutely right. As mentioned above, I confused "repliers" and
"bouncers".
- Ole (thoroughly castigated, thus enlightened :-)
Re: Using SA to prevent bouncing spam?
Posted by Sanford Whiteman <sw...@cypressintegrated.com>.
> Hi, in order to avoid bouncing spam back to the (almost certainly) faked
> sender-addresses, I thought I could use SA directly:
What's your MTA and/or SA-invoking app? Surely it is easier to have
that agent parse SA's feedback (headers, subject mod or score) in
deciding the final disposition of the msg than to try to trick the MTA
into dumping the mail.
Please elaborate on the use case in which you can't use MTA processing
rules to prevent backscatter, given that you trust SA markup
completely here, right?
--Sandy