I don't understand what that has to do with using another fake MX to
capture SPAM.
Instead, it worth the while to setup such MX only to evaluate if there
is a consistent stream of emails which can be captured and tagged as
SPAM (because they would be 100% SPAM) for improving spam assassin
evaluation or forwarding to capture engines.
The most annoying SPAM we are having here is 'local SPAM', going to
normal MX: small unsolicited mailing lists which are too small to be
catched from big engines, but still very annoying.
Regards,
Tonino
Il 28/04/2014 19:54, Dan McAllister ha scritto:
OK, I'm johnny-come-lately to this discussion, but let me add my
2-cents worth in here:
FIRST: Users who want to switch mail providers or mail server
technologies -- but have no changes on the client end are
/*dreaming*/. I tell my clients that I can minimize the changes, but
the more I minimize the changes, the higher the cost. (It's kinda like
buying a new car and expecting the dealer to move all the crap from
your old car into the new one, including copying the radio station
presets and getting all the trash located in just the same spots --
even though the new car has XM radio and a glove box, while the old
one did not.
Converting from one mail server type to another can be tricky, and
should be done with great care. Some of the gotcha's:
- When you've switched from one MX server to another, some remote
SMTP servers may still try to attach to the old server
RESOLUTION: Create a forward (or smtproute) on the old server to
force delivery of new messages to the new server
- When you're migrating IMAP folders, there can be different
limitations (some IMAP servers allow a space as the first or last
character in an IMAP folder, others do not. Some allow special
characters, others do not... and so on)
RESOLUTION: Provide a method to allow users to copy their own
folders from the old server to the new (alternatively, you can do it
-- but then you're increasing your workload unnecessarily... or else
charge for it.
There are plenty more, but those are the ones that quickly jump to mind.
Dan
On 4/28/2014 1:15 PM, Tonix - Antonio Nati wrote:
Il 28/04/2014 18:12, Eric Shubert ha scritto:
On 04/27/2014 01:38 PM, Hasan Akgöz wrote:
Hi Eric,
The first time I heard you specify the subject. I think this method is
not a good idea. becuse If you mess around with MX records, you
deserve
to have lost mails and angry co-workers/customer etc... :).
Are you suggesting that there are legit servers that can't handle
such a configuration?
Before I quitted my email service (I migrated to a collegue wich
manages a lot more accounts than me), I was considering to use this
way to capture spam on my servers.
Only problem I see this high priority MX may be active only if
another low level MX is active, otherwise it will classify everything
as SPAM, and a simple reboot of main MX may be troublesome.
So, the main problem is to keep this spam MX up only when lower
priority MX are up.
Tonino
Try ASSP ( Anti-Spam SMTP Proxy Server ).
I've looked at ASSP in the past. I don't see a point in having both
ASSP and spamdyke. If someone can sell me on ASSP over spamdyke, I'd
be happy to look at it again.
Is anyone out there using ASSP with QMT?
And DNSBL,SURBL,SBL,RBL (zen.spamhaus.org
<http://zen.spamhaus.org> and spamcop.org <http://spamcop.org>).
I presently use:
dns-blacklist-entry=b.barracudacentral.org
dns-blacklist-entry=zen.spamhaus.org
I dropped spamcop due to problems they've had with FPs.
Thanks Hasan.
--
IT4SOHO, LLC
33 - 4th Street N, Suite 211
St. Petersburg, FL 33701-3806
CALL TOLL FREE:
877-IT4SOHO
877-484-7646 Phone
727-647-7646 Local
727-490-4394 Fax
We have support plans for QMail!
--
------------------------------------------------------------
Inter@zioni Interazioni di Antonio Nati
http://www.interazioni.it [email protected]
------------------------------------------------------------
