On Mon, 1 Oct 2018, Rob McEwen wrote: >On 10/1/2018 5:23 AM, Benoit Panizzon wrote:
>> * Require SMTP Authentication. So much is now via stolen credentials (which your other checks try to handle) that this does nothing to prevent, of course, but it is indeed reasonable and responsible of you to deny relaying except with some kind of authorization and accountability/traceablity. (Primarily noted as a lead-in to the following ...) Have you looked at providing multiple credentials, e.g., OAUTH2 or merely additional auth-for-email-only alias credentials within your systems? It doesn't prevent them being stolen but it limits the colateral damage that invalidation/limiting/blocking causes. >> * Keep cache history from which IP an SMTP Authentication occurred. >> * If count(IP) in delta time > IPlimit block account and require >> password change. >> * If count(geoIP) in delta time > Geolimit block account and require >> password change. It must be terrible to roam with your phone but leave your PC on at home, each checking e-mail. Multiple credentials can help with this too though it does add complexity. >> * If count(recipients) in delta time > RecipientLimit - tempfail and >> notify postmaster to check manually. In addition hopefully you run much of the same SPAM checking on the messages they're sending as you use for messages you receive from non-customers, instead of bypassing all checking, e.g., skip "PBL" checks (which I don't think much of anyway) but perform content scanning and check all other BL's you use -- if a customer is on the CBL or a droneBL, etc., they should only be able to write to your admin and support addresses even if the message appears squeaky clean until the matter is cleared-up (thence into an RPZ temporarily to remove them from your local view of those lists and/or tweaking of the content rules perhaps just for them). >Start limiting the ability of your end users to set up forwarders for >email accounts forwarding to freemail addresses. Alas people do that not only because they are sheep, but because they like the interface (perhaps sheepishly) or at least more than they like what you provide, and for other reasons so about all this will do is nudge/force them to go elsewhere, which is great if they're spammers or shady. Good mailbox providers have the ability to pickup mail, which includes all the majors, and that should be encouraged instead of forwarding but you'll get push-back on that because there's more to configure and it doesn't absolve you of being deligent, i.e., a forward is usually a single change (odds are it isn't even verified first -- it should be), but to enable picking up means configuring an(other) email client which most mailbox providers try to make easy but it's still more to check even if all the automation / guesses are perfectly correct. >The problem in general is that they [hotmail/outlook, generally ms] >often view any spam that slipped past your filter and made it to that >mailbox's forwarding - as being a spam that YOUR mail server sent. Because your server did indeed send SPAM -- it just wasn't the origin -- and it might send more so it should be(gin to be) limited. Alas your notions of SPAM may not agree with theirs, but you must try. Even if the mailbox provider fetches messages it isn't sufficient to skip checks as that often earns your server/domain/service black marks just as if it tried to forward the same message, indeed it might be good to require that less than squeaky clean messsages go into a folder other than the (usually one) folder that the mailbox provider fetches or that you'll forward -- alas the customer usually doesn't like this. >it doesn't help that many end users are click-happy on the "this is >spam" button when going through their hotmail/outlook mail, often using >it in place of the "delete" button! Not only that but if the subject is too clear they might delete the message "unread" which amounts to calling it junk/SPAM yet if it isn't clear enough they might discard it out-of-hand which amounts to the same thing. /mark _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
