On Mon, Oct 1, 2018 at 2:35 AM Benoit Panizzon <benoit.paniz...@imp.ch> wrote:
> 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. There's a fine line with this one. As long as you're doing a good job filtering out the spam before forwarding, using something like SRS can be useful as you point out. OTOH, if your SRS domain authenticates (usually by SPF), then you'll accumulate the reputation for everything you forward. We do try to know that something was forwarded, but it's far from full proof. I'm not sure if it would be better then to deliberately leave your SRS domain SPF not including your mail servers or not. We've typically recommended forwarders to not rewrite the envelope sender when forwarding for this reason, but that was mostly pointed at tech folks running their own servers (this page has a section for procmail https://support.google.com/mail/answer/175365) For providers, you'll have to judge for yourself. I'm hopeful that ARC will be another useful tool for this kind of forwarding, but that remains to be seen. Brandon
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
