We have implemented a stand-alone dedicated Anti-SPAM solution for our customers for which we have brought online separate servers.
The easiest way we direct mail to this service, is by MX’ing the domain to the appropriate guarding server. In the software configuration, we then give it the return relay server to send mail back to.
However, when sending an email on an interworx server from domain1.com to domain2.com both hosted on the same box, its bypassing the MX record.
We could just remove it from vpopmail, however as the anti-spam sits before the interworx server, we still need the full functionality of vpopmail for email accounts etc, on the interworx servers.
Do you have any recomendations on how to make the internal mail daemon check MX records for all domains, not just external ones?
There’s a fundamental problem here - what you’re proposing is for qmail to sometimes forward the message to the MX, and sometimes not. Let me explain.
When a message arrives, the qmail-queue program looks at the e-mail, and determines which type of delivery this message needs - local, or remote.
Local means the message should be delivered somewhere on “this” server - this is the final destination for this message.
Remote means the message’s final location is elsewhere, and will get processed by the qmail-remote program, which does the MX lookups, and SMTP communication to pass the message on to the next hop.
So, you want your qmail server to delivery mail locally - but only if it’s already been through some other server (the anti-spam one) first. But qmail doesn’t care about that. It just has a list of domains that it is responsible for, and those go in the local queue, and all others go to the remote queue. If you made qmail force the message to the “remote” system, when the message came back from the anti-spam box, qmail would stick it back in the remote queue rather than deliver it, and you’d have an infinite loop on your hands.
I see two scenarios where mail is initiated from the InterWorx server - php/cgi scripts on the webserver, and mail from authenticated users (since the MX for the domains isn’t the InterWorx box, outside mail shouldn’t be coming to the InterWorx box directly, it should go through your spam setup first). Which of thses two (or is there another scenario?) are you trying to force through the anti-spam setup? Is it malicous user@domain1.com spamming user@domain2.com? If so, get rid of that malicous user! If it’s the php/cgi mail originations you’re trying to control - the php/cgi scripts doing the sending probably need to be fixed so they don’t allow spammers to exploit them in the first place.
I’m not saying those two scenarios are what you’re trying to solve, I’m just trying to find a way to help, since having qmail on the InterWorx servers do BOTH remote and local delivery for a certain domain isn’t possible.
After reading your very first sentance, I knew what was coming, and realised that what I was asking for was just plain stupid - that’s what you get for thinking on a Sunday!
What tripped me to look at it, was that we sent a mailshot out today to customers (coincidentally, about the spam service) and as I was chatting to a Reseller, who had received the email he said, well this one hasn’t been scanned (he was using the anti-spam service). I thought, dang, need to look into it.
But given what you’ve said, if they’re spamming as an authenticated user = get rid of them. If a form is doing it badly = get rid of it.
So thank you for the very detailed explanation Paul. It is much appreciated and has served to greater explain the mail-processing process.
On a side note, on our own domain, we have gone from (un-filtered) 1500 spam emails a day down to about 4! That’s what I like to see
On a side note, on our own domain, we have gone from (un-filtered) 1500 spam emails a day down to about 4! That’s what I like to see
Intresting to know what is the anti-spam software used?
However, due to the fact that it costs per user and we have brought online dedicated servers just to run the appliance, we have put it to our customers as an extra, chargeable option on top of their hosting account.
We’ve also got a white label service for people/hosts who dont have the time nor resources to invest in a dedicated appliancewho can resell the service to their own customers.
It’s proving very popular. Obviously people have the ‘included’ SpamAssassin free of charge with their hosting account, but for those requiring that little bit more, they can now get it.
We ran our domain without any filtering for about a month just to see what sort of levels we were getting. Since routing our stuff through the service, our support desk hasn’t received one spam email (usually about 60-80 a day), personal boxes haven’t received any and the catch all has received just a very small amount.
There is also an OCR ‘bit’ built in which is looking at the new type of spam that includes text embedded as an image.
One of the requirements is that catch-all be turned off. I make sure all catch-all is turned off, but even then, I get a email from provided telling me their catch-all detector is detecting that both my IW servers show catch-all is activated. And terms of service states I must shut catch-all off.
I am like Everythingweb sending mail to the dedicated anti-spam server using MX record. However I was told the IW servers are allowing all emails into the server.
I am a little baffled with this, do I understand that the server allows all emails into the server then somewhere along the way InterWorx nulls the email, maybe after the MX?
I might be in danger of loosing the service, and like Everythingweb has said, we are not getting any spam any longer and the customers of mine that are using it are loving it.
If you are MX’ing the domain to the spam server, then in theory your Iworx box is the last loop in the chain before being downloaded by a user.
If what you are doing is setting your Interworx srever as a secondary MX, then I would suggest remove it. Most if not all 2ndary MX servers tend to have little or no spam protection on them, so spammers are now sending straight to the second MX hoping to circumvent the primary spam filtering methods.
Do you have catch-all OFF with bounce ON? Or is bounce OFF? They may be looking for a bounce to test of catch-all is on or not, and of bounce is OFF, it’ll just silently accept messages for nonexistant users and blackhole them.
Do you have catch-all OFF with bounce ON? Or is bounce OFF? They may be looking for a bounce to test of catch-all is on or not, and of bounce is OFF, it’ll just silently accept messages for nonexistant users and blackhole them.[/quote]
With reference to R-n-R’s issue, we’re their Antispam provider and here’s the problem:
Mail should be rejected during the SMTP transaction if the RCPT TO is an unknown user. A 550 should be generated. This isn’t happening…
The way we test is very simple: we generate a random string about 40 characters long and then stick it on the front of @domain.com and start an SMTP transaction with the server, using the randomly generated email address as the RCPT TO. If the server responds with a 250, it fails our test.
The reason for this is that our antispam appliances need to know which email addresses are valid and which aren’t for statistics and quarantine tracking purposes. If the server doesn’t validate users during an SMTP transaction but accepts all mail (even if it is going to bounce it back later), our appliances view it the same way as a catch-all… the server accepts ALL mail for the domain.
If I remember correctly, InterWorx is using qmail, correct? My understanding is that there’s a patch (chkuser 2.0) for qmail to fix this problem.
On a side note, on our own domain, we have gone from (un-filtered) 1500 spam emails a day down to about 4! That’s what I like to see
I recently converted from Mailfoundry over to Postini and liked it so much that I’m now an authorized reseller. It’s extremely accurate (and cost effective) because it doesn’t require the purchase of anti-spam appliance(s). I went from getting about 5 spams a week with Mailfoundry to 0 with Postini, so I’m thrilled =]
Also in regards to checking remote MX records and such prior to sending mail to a domain that is hosted locally, as you are trying to pass it through a remote spam filter… what is the point? If you can’t trust your own local users not to spam you, maybe you should get rid of them? I know this is not what you are getting at with what you said, but what is the point of passing it through a remote spam filter first?
We have mail being delivered to our local queue that is for a domain we do not host mail locally. Why is this happening? I checked the /var/vpopmail/domains folder and the domain in question is not in there. Is there something else that triggers mail to go into the local queue? Is there a way to move mail from the local to the remote queue?
I’m also noticing messages in the remote queue that are simply not being sent and I can’t see any reason why.
Is there a way to move messages from the local queue to the remote queue? Somehow I ended up with messages in the local queue sent from a web form we host but we don’t host their email, so it should be going to the remote queue.
I’m having something similar happen. We use an external spam filter service called MX Logic (much like Postini) so all our MX records point to their servers. However, a lot of spammers (especially here recently) are simply sending mail directly to the our server’s IP address. Basically, they’re picking up on the A records for mail.domain.com and are sending directly to that instead of using our MX records. Is there some way we can block remote mail from coming in without going through our MX records? MX Logic actually suggests locking down port 25 with our firewall only allowing their list of IPs to get through. However, not all or our domains are using the service. So, if we did something at the firewall level, it would need to be domain specific. Is that possible? I’m beginning to feel that an external service doesn’t do us much good if spammers can just avoid the MX records.
This would be a nice thing to know… just so you know, the spammers aren’t targetting the IP of your domain, but rather cached records of your MX entries. Some of them keep these caches for years in order to save alot of bandwidth on doing all of the DNS lookups. Anyway, I hope that the InterWorx team replies with a solution to this, it would be pretty useful!
Well, the reason why I feel it has nothing to do with a cached MX record is because we just moved all of our sites to this new Interworx server with all new IP addresses.
If it’s the php/cgi mail originations you’re trying to control - the php/cgi scripts doing the sending probably need to be fixed so they don’t allow spammers to exploit them in the first place.
