Hey, > On 09 May 2016, at 00:24, Daniel Margolis <[email protected]> wrote: > > Sorry, everyone. I've been out of the office the last few days on holiday and > haven't had a chance to catch up on the whole thread. >
Me too,.. > Regarding big providers' ability to monitor for misconfigurations, I think we > should not assume they will always catch errors. Especially in the early > stages of deployment, as Viktor noted, a small percentage of dropped mail > could go unnoticed, so having a means to accurately report failures and their > causes strikes me as valuable to everyone. Anyway, I'm not really seeing an > argument that only certain classes of mail hosts would benefit from this, and > of course that's not anyone's goal. Big providers, and nowadays even smaller ones, use config management, cluster schedulers, queueing frameworks et cetera (not an unsolved problem after all) -- but small mail ops do not. Please keep that in mind, guys. > These don't strike me as mutually exclusive. Having an in-band indicator of > why the sender terminated the connection (like "STARTTLS wasn't supported and > I require it") seems useful. Having out-of-band aggregation also seems very > useful. +1 > > In particular, one of the methods by which we would hope an intermittent MITM > would be revealed is that reports of the occasional STARTTLS failure would > indicate exactly this. If reports can only be sent during the MITM to the > MITM'ed MX, this property is lost, is it not? Yes, but it also depends how the MITM is attempted. Sometimes an attacker might not resort to all "tools" available, or it may be a simple scripted attack without any insight into what's happening real-time. Aaron
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
