> Hi Ken, > > > > awesome. Thats a bunch of helpful steps! Thanks a lot! >
I'm a few years removed from directly administering a 'real' mail server (directly, at least) but I have some observations about Ken's list: > > * Monitor abuse@ and make sure that this address a) exists for your > client > domains and b) you receive a copy of messages sent to them. Tough call mandating the existance and handling of abuse@ for client domains, nevermind actually receiving email that belongs to clients! Clients should be advised to run the RFC-specified email addresses, but they're responsible for their conduct. If someone reports to me that one of my customers is engaged in abusive practices (or compromised, perhaps) then i'll take action directly, but they should have the chance to solve their own issue (or identify malicious false-positives, perhaps) before their service provider has to get involved. > * Restrict access to the submission port to either the client IP range. When authenticated SMTP is offered as a service (essentially a must for mobile support), IP address restrictions are counter-productive. The usual 'don't be an open mail relay' rules apply of course. > > * Lock accounts after X failed logins and get an alert about that. I do support this to an extent, but this is also a DoS vector. Alert, yes. Lock? Not necessarily. > * Have a third (failover/fallback) sending capability with a different > data centre. Periodically route enough email though that to ensure that > it will not be throttled in case you need it. But, don't use it as a > primary. I agree with this in principle. Not sure how straightforward it is to do it in practice, but an alternative SMTP option is useful. > * Understand what your normal usage profile looks like - graph the mail > > queues. This will help you build policies / tech. around detecting > unusual behaviour. E.g. tougher throttling outside of business hours > etc. This could have merit, depends on the nature of those using your service. > * Add a custom header (X-abuse) to make it clear where the email came > from > and how to report abuse of your service. Yes, supported. > * Make it clear on your website how a non-customer can contact you to > report abuse. Also supported... consider https://github.com/securitytxt/security-txt as well. > * Run a cut-down spam filter on the outbound mails (look for stuff like > > freemail reply to addresses, fuzzy checksum hits, spam URLs). Some of > > that will be false positives so just put it into a holding queue and > create a service desk ticket for it to be reviewed. Spamfiltering outbound mail is a great idea, as it'll help preserve your reputation, and that of a customer, if they get compromised and someone starts taking advantage.e But putting suspect email in a queue for your own service desk is questionable IMO. Notify, Alert, absolutely, but again, unsure if you should bog your own service desk and essentially tarpit outgoing email,... I'd say refuse outright (5xx error) and let the sender unpick it. No black hole ambiguity. > * Have a clear upgrade path if case they wish to send marketing emails. > If > you don't, they will just try to send them through your platform. > * Publish an Acceptable Use Policy (AUP) and make them agree to it as a > > pre-condition to using your service. Spamhaus have a good template to > > start from on their website. The above kinda relate, the AUP is a given (anyone offering a service should have one, regardless of the service, pretty much!) and that should include the nature of what the threshold for marketing emails might be before an alternative product needs to be considered. > * Monitor bounces and tie that it with your monitor solution. Yes, if you can. > * Monitor the health of your clients connecting IPs (and possibly > website). Any indication of a compromised site is grounds for locking > > the account until a human can review. For suspected compromises, yes this is great... your T&C needs to permit you to immediately suspend service if you think an account has been compromised, as a risk and damage mitigation factor (your IP's rep on the line, thus, the deliverability of all your other customer's emails). Customers don't tend to think about this until they're blocked, then they get grumpy.. so if they know about it ahead of time, you're covered. GLHF Mark. _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
