I believe what is being detected with this technique is when you have a user login from place B when up until then, they have always logged in from ASN(Work IP A1), ASN(Home IP A2) and ASN(Cellphone IP A3).
So the connection from IP B suddenly becomes quite suspect, especially if the GeoIP data on it is from a different country. Maybe not enough to block the send, but certainly enough to, for instance, YMMV, send out an SMS challenge. Aloha, Michael. -- Michael J Wise Microsoft Corporation| Spam Analysis "Your Spam Specimen Has Been Processed." Got the Junk Mail Reporting Tool ? -----Original Message----- From: mailop <mailop-boun...@mailop.org> On Behalf Of Alessandro Vesely Sent: Wednesday, October 3, 2018 2:17 AM To: mailop <mailop@mailop.org>; Benoit Panizzon <benoit.paniz...@imp.ch> Cc: Brandon Long <bl...@google.com>; Michael Peddemors <mich...@linuxmagic.com> Subject: Re: [mailop] How to find 'low flying' spamers? (Re: outlook.com blocking reason: S3150 "network is on our block list") On Mon 01/Oct/2018 11:23:15 +0200 Benoit Panizzon wrote: > > * Keep cache history from which IP an SMTP Authentication occurred. I'm curious about this technique. Currently I block by IP and whitelist by domain, so I must be missing something in between :-) How long does that cache last? At what step do you look it up? How can you tell IP relocation from multiple domains hosted by the same IP, do you apply a fixed time lapse? Would you pass a message with a broken DKIM signature if the IP it came from usually authenticates for the same domain? DMARC specs don't seem to provide for occasional, sporadic DKIM failures, which we know do happen. There is not even a PolicyOverrideType for that... On Tue 02/Oct/2018 01:57:19 +0200 Brandon Long via mailop wrote: > > I can only speak to what Gmail prefers. I don't know how many other > systems work similarly to ours, but the logic is that if you rewrite > the envelope sender and then SPF auth that sender, you're basically > attaching your domain to the message, and you'll accrue reputation > based on it. Obviously, that is already happening to your IP, but you > could imagine an IP:auth domain reputation pair being able to separate the > streams, logically. Right. It's easy if forwarded messages have a valid, possibly aligned DKIM signature. In general, there are multiple auth names for a single IP. Do they all get cached? For the author domain, the IP has to be saved even if auth methods failed to verify, in order to send DMARC reports. What about the rest? > Also, rewriting the sender opens you up to auth based privilege > escalation, the message that was forwarded now auths as the forwarding > domain. ARC helps there, though, since it allows you to see the > inbound auth levels and see where the escalation occurred. If ARC serves anything, that is it. ARC-sealing is one of the two things forwarders should do, IMHO. >> (Surprised how many weak SPF records are out there, wonder if they >> weakened it up because of SPF checks in forwarded email..) >> >> Kind of defeats the whole idea of SPF when the policy is weak. > > SPF was defeated the second it was proposed. Mail forwarding is not > going away. Because of the way SPF works, IP whitelisting is key. To honor reject-on-fail before receiving the body implies a thorough whitelisting. That is what SPF specs say. The other thing forwarders should do is to subscribe to as many white lists as they can, no? (Domains can also specify a public whitelist in their SPF record, although that might be a dubious practice.) Best Ale -- _______________________________________________ mailop mailing list mailop@mailop.org https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchilli.nosignal.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fmailop&data=02%7C01%7Cmichael.wise%40microsoft.com%7C201a9f86659f464b0c8208d62912d4d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636741558210395005&sdata=hJfIZJqWiCz8u4YrvE5nPwyZKgF6wwqhBUTcWjEjIwQ%3D&reserved=0 _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
