Marc Perkel wrote: > I'm doing an experimental free MX backup service and wondering if it > will get exploited. I'm wondering if I'm overlooking anything obvious? > Here's the info on it: > > http://www.free-mx-backup.com > > The idea is that it detects if we are the secondary and not the primary > MX and will store and deliver email for those domains. I'm trying to > think if I'm leaving myself open for anything I'm going to regret. If > you were a spammer how would you take advantage of this?
There's loads of challenges to deal with and think about when running a secondary MX serivce: 1) If the primary MX rejects any mail that you are attempting to deliver - then it will make your service the source of backscatter as your MTA will then generate a DSN (as you accepted the mail for relay and it was subsequently rejected by the upstream server). Causes of this: - Invalid recipients; call-ahead recipient verification is needed to mitigate this - however as you are a backup MX; the primary might be off-line - you still therefore need to accept the mail in this case. - Stronger spam enforcement on the primary that rejects messages at SMTP time. 2) Greylisting - if the primary MX is using it then your secondary service will render the greylisting completely ineffective as when the primary greylists the connected host, then it will most likely immediately try your secondary and you'll accept it and then pass it to the primary which has to accept it from you. What you say on your website is incorrect - you *will* render it ineffective and it will cause additional problems for the primary (see point 3). 3) Mail received by the primary from the secondary will require content filtering which is way more expensive than connection-based filtering such as RBLs. 4) The policies of the primary and secondary must match. If the primary is using zen.spamhaus.org then so must the secondary (otherwise the secondary will simply be a source of all the spam the primary rejected). The reverse is also true - if you have more aggressive filtering on the secondary than the primary then the risk is that you will reject mail that end-user actually wanted. If you think you will only see bad connections on the secondary MXes then you are very mistaken - what happens when the primary gets busy and stops accepting connections, when the host reboots (more common in the Windows world that you'll most likely attract) or when the primary's connection goes down etc. plus you'll still see genuine senders hit your service first due to IP connectivity or routing issues to the primary or due to some other software fault - in all these cases your policies are then enforced on the end-users e-mail and FPs here will hurt you a lot (as you're in the US I'd be worried about getting sued). To mitigate this you'll have to be up-front about all the methods used that could cause SMTP time rejections and be clear about what this could mean to the end-user. 5) Privacy concerns; potentially a domains entire mail stream for the last 5 days could be held on your mail spool. This has obvious privacy implications for most people particularly as there is no contract between you and the end-user. How does the end-user know that you've delivered it all? Or that you haven't copied or read it? There's probably a whole load of other issues I haven't considered - but these are at least what I could think of immediately. Cheers, Steve.
