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://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
