Hi Benoit, I assume you already checked M3AAWG's BCPs? https://www.m3aawg.org/published-documents I'm not familiar with _all_ of them, but that's a good source of ideas anyway.
Cheers, -- Benjamin -----Original Message----- From: mailop <mailop-boun...@mailop.org> On Behalf Of Benoit Panizzon Sent: Monday, 1 October, 2018 11:23 Cc: mailop@mailop.org Subject: [mailop] How to find 'low flying' spamers? (Re: outlook.com blocking reason: S3150 "network is on our block list") Hi List Well thank you for all the hints. I also (thanks to Al) found out, that you need to set the browser language to english, to get to the propper help page where the delisting request form can be found. With german, you're lost :-) But I would like to use that topic on a discussion about what to do to mitigate abuse of an ISP email platform. I believe we do much to mitigate abuse from our email platform, but perhaps, there is more that can be done. So tell me how you 'do' it and where you see potential for improvement. First let me explain what we do... We are a classical end user ISP. Our customers are private households with an internet connection and some companies. We encourage companies to use an own mailserver. We do not offer any 'relay' services to them, so we won't get the crap some hacked company servers produce via our mail platform (of course our abuse desk also deals with them, to notify those customers in our AS). So we mainly get the usual problems with customers who hand out their email credentials in reply to phishing emails or get trojans who steal them from their computers. To mitigate those problems we have implemented those mechanisms: * Require minimal password strength. * Require SMTP Authentication. * 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. Some exception for google services and local mobile networks NAT which use a different ip for each SMTP connections. * If count(recipients) in delta time > RecipientLimit - tempfail and notify postmaster to check manually. We also use account encapsulated SRS for forwarded emails, so we can detect bounces from the far side and deactivate bouncing forwards to limit backscatter to a minimum. Of course, this fails if the phished account keeps below our radar by using a single ip address and sending emails slowly to keep below the tempfail threshold. In this case we rely on feedback loops to 'react' and also sometimes on customers reporting the bounces their phished account produces as spam :-) What else could we do? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________ _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
