Re: Using SA to prevent bouncing spam?
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?
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?
Den 14.08.2006 kl. 19:48 skrev Sanford Whiteman [EMAIL PROTECTED]: 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 [EMAIL PROTECTED]) 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 [EMAIL PROTECTED]: 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 [EMAIL PROTECTED]: 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?
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 [EMAIL PROTECTED]) 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?
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 [EMAIL PROTECTED]) 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?
Den 15.08.2006 kl. 12:01 skrev Andreas Pettersson [EMAIL PROTECTED]: 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?
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?
Ole Nomann Thomsen wrote: Den 15.08.2006 kl. 12:01 skrev Andreas Pettersson [EMAIL PROTECTED]: 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?
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 [EMAIL PROTECTED]) 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?
Ole Nomann Thomsen wrote: Den 15.08.2006 kl. 12:01 skrev Andreas Pettersson [EMAIL PROTECTED]: 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
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?
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
Re: Using SA to prevent bouncing spam?
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 pgpOPoY5axDd2.pgp Description: PGP signature
Re: Using SA to prevent bouncing spam?
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.eduCollege of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include std_disclaimer.h
Better is not better, 'standard' is better. B{
