Re: [mailop] SPF (and other email security protocols) Survey
On 11/23/22 8:38 AM, Slavko via mailop wrote: Anyway, using SPF on shared environment is something, what negates SPF purpose at all, as anyone from that shared provider can succesfuly pass SPF for any other domain in it (sharing the same TXT records). Thus in these shared services is SPF mostly cosmetic or part of PR/marketing only. Whole result then depends only on that, if particular provider checks spoofing from own customers, which is a) not published and b) moves trust to smewhere else. I don't agree with SPF being mostly cosmetic on a shared hosting environment. Yes, other people on the same host can send messages without authorization while still passing SFP checks. However, others, not in said shared hosting environment /can't/ send messages while still passing SFP checks. The difference is in the scope of who can pass SFP checks, the /just/ the shared hosting environment verses the entire Internet. I believe there is some value in SPF even in a shared hosting environment. It's just less value than in a dedicated hosting environment. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF (and other email security protocols) Survey
On 2022-11-23 at 13:54 +0100, Tobias Fiebig wrote: > But I am currently stuck at 'getting a /23', which is surprisingly > difficult without $30k to blow... so if one of you has some spare v4, > I wouldn't say no. ;-) IPv4 addresses are scarce now, but universities and NRENs were assigned large ranges back in the day (with lots of unused IP space). Given they are the ones that would primarily benefit from your measurement AS, I would ask them to lend you some ranges. Kind regardxs ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF (and other email security protocols) Survey
On 2022-11-24 14:01, Tobias Fiebig via mailop wrote: And to circle back to on-topic: The result of that is what then pops up in /var/log/maillog. So it isn't about 'should VT change [something]'; It is more 'shouldn't society change the incentive structure and general setup around academia as a whole'? I have quite some opinions there, boiling down to the answers 'yes' (and suspect most here will agree with that). But that is not really in my power; So I try to do what I can instead (channeling results of the system into a more manageable frame, while trying to teach those students I directly work with at the institution I am at). At the risk of being frowned down upon for this for being arguably off topic or mean-spirited, I feel I must venture an opinion, even as a tiny operator, because I have had extensive experience with how academia works and have dealt with this repeatedly. This "oh what can I do, woe is me" responsibility-diffusing rhetoric belongs with junior, recently hired teaching assistants, not professors with tenure. Isn't it professors who, after all, in fact run the universities? Who provides and sets the academic standards and practices, if not they? Who populates the commitees? Or do we further diffuse responsibility for bad research practices up to the govenment, another academic trope? Who is this "academia"? How about a more honest: "This is how the questionnaire is and will remain, we have no time to change it now, feel free to not fill it in. We'll do better next time" and be done with it? Because I didn't see any willingness to change something in the questionnaire in light of the criticism in this forum. * How about adding info to/changing the upfront consent statement? * Making questions optional is not really confidence-inspiring, feels like a quick fix solution to "get on with it", a practice I've seen used when there is no time to go over and redo a questionnaire due to having to get it through committees again. * You claimed GDPR work was done. Is surveymonkey more GDPR-compliant than Google forms? How about using your own self-hosted platform, for example? They're zero cost, secure and easy to set up and I would trust something you self-manage more. Surely you have the know-how. All that said, I am all for research on the subject of mail protocols and practice and sincerely hope this work produces useful results, hopefully also truly representative of practice in the field. Good luck to you. Best Regards, G. Miliotis ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF (and other email security protocols) Survey
Hello Andrew > If VT PhD students don't have the experience needed in the topics they study, > then shouldn't VT change either the students or the topics ? As I said, this is not about specific instances, people, or VT in particular. It is more of an observation that while in 1988, you could go through RFC1031-1035 and have a rather complete overview of DNS (picked as an example here). That changed since then, not only for DNS; Mail, TCP,... they all grew. A lot. At the same time--sticking with DNS here--countless ways of 'holding it wrong' emerged in practice, far beyond RFC1537 and RFC1912. And to do proper measurements (in terms of 'not unethical' and imho also in terms of 'actually reliable') you MUST know all of this. When I look at the people with whom I graduated my master, who went on to work on DNS implementations: They spent _at least_ as much (likely more) time on DNS alone as I did on my whole PhD. And a PhD comes with a lot of other things added to it (teaching, funding, different topics); It is more like a mixed bag of beans. And still they will _always_ know more about DNS than me. Which brings us to the academic-philosophical point: Technically, I would expect a PhD to be exactly about that: Having the time to _really_ dig into something, getting to the bottom of it, and making meaningful contributions to the state of knowledge; if it takes five years, a decade, or more. But then again, as said earlier in this thread, I tend to be a bit (too) idealistic. Nevertheless, from your message, I believe that we actually agree on this. Closing the loop: Academia has grown into an output focused, measured, and managed ecosystem in many places*. People have 4 (EU) to 6 (US-ish) Years for a PhD, with an expectations of 3-5 papers in well regarded venues. There is simply not the time for engaging sufficiently deeply with many technologies, and--throwing another punch here--I think many CS BSc/MSC programs also do not necessarily provide the right foundation for that. Teaching is another chore many faculty run through, while all things fall of different corners of the plate at the same time (and far too often faculty members' mental health as well; Burnout in academia is a thing). And to circle back to on-topic: The result of that is what then pops up in /var/log/maillog. So it isn't about 'should VT change [something]'; It is more 'shouldn't society change the incentive structure and general setup around academia as a whole'? I have quite some opinions there, boiling down to the answers 'yes' (and suspect most here will agree with that). But that is not really in my power; So I try to do what I can instead (channeling results of the system into a more manageable frame, while trying to teach those students I directly work with at the institution I am at). In any case, I believe that harsh words when something (predictably and repeatedly) goes wrong with that system in place will not bring us closer to a solution. With best regards, Tobias *I am not really planning to make a full argument on why I believe that this approach is really detrimental to the acquisition of knowledge and education of students; It is beyond the scope of this ML, and I assume I'd be preaching to the choir. If you are more interested in this, I can recommend a (somewhat recent) measurement study of mine into/tangential to the topic; The discussion actually touches on some of these points, and provides good pointers to further work on it: https://arxiv.org/abs/2104.09462 ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF (and other email security protocols) Survey
On Wed, 23 Nov 2022, Tobias Fiebig via mailop wrote: We can have an awful lot of discussions about this, and there is a lot going on; Besides the obvious 'is it good or not' and 'is this really science?', we essentially deal with 'science' with all its incentives (publish or perish); This means trying to do research on Internet protocols that have been around for longer than the combined age of the PI and PhD in many cases; PhDs fall out of their masters before getting into such a topic, and then essentially have a year to know all the ins and out of a protocol that grew over the past 40 years... because after the first year they _should_ basically have their first paper under submission. Certainly people that haven't run their own mailserver/authNSes for more than a decade. Yes, recipe for disaster. IIUC the first PhD candidates were not raw graduates but experiences practitioners in their field; a PhD as a research training came later. Although I *did* start a PhD in Maths/Computer Graphics straight after my BSc., my brother worked as a hospital doctor for several years after qualify before starting his MD (which not the standard medical degree in the UK) and a friend of my wife's practiced alternative medicine for many years before starting a PhD in that area. If VT PhD students don't have the experience needed in the topics they study, then shouldn't VT change either the students or the topics ? -- Andrew C. Aitchison Kendal, UK and...@aitchison.me.uk ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF (and other email security protocols) Survey
Heho, > Please, give us the IP ranges these clowns are using so we can block all > traffic from them. Not sure which 'clowns' you refer to; If this is about the sum of researchers under the mechanics of current academia which might release crappy measurements to the public, I sadly lack such a list; If I manage to get the circus^Wmeasurement AS going I will certainly share the prefixes (and ASN) for people to block. After all, that is part of its point. If you are referring to Tijay: Stuff is being built on EC2, and I leave it to Tijay if he already wants to share the IPs; However, as long as I can and want to give some input on that project, that SPF measurement setup will not originate any measurements until some issues are resolved. So, I am not sure how much of a point is in that at the moment, especially as those addresses may still change. If and when those issues are resolved whatever IPs it will be running from will be first communicated, with enough time for people to take measures. With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF (and other email security protocols) Survey
It appears that Tobias Fiebig via mailop said: >My argument was that it is hardly possible to gain a sufficient understanding >of many protocols to be able to thoroughly design network >measurements while accounting for all possible harms within the time available >for a PhD. I happen to have a PhD in computer science, and if that is your experience, I feel sorry for your students. I also wonder about the kind of department that would let students do that kind of "research" without supervision from faculty who are sufficiently familiar with the field to ensure that their students do real work. "Are SPF lookups making too many queries" could be a plausible master's project but it's way too trivial for a PhD thesis. Please, give us the IP ranges these clowns are using so we can block all traffic from them. R's, John ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF (and other email security protocols) Survey
Hello John, > So if they were competemnt and ethical, tney would stop and find people to > work with who understand the issues so they can do research that is not > abusive and could have useful results. Unfortunately, as we have seen, they > are neither. I personally believe (and sincerely hope that my believes are not disappointed here) that this stopping, reflecting, and improving is currently taking place, and has been for some time, as signified by no new mail measurements I know of having hit the world from the group so far. > Having spent my entire life in and around academia, I have no sympathy for > people who say that since we are so nice and our goals are virtuous it > excuses the stuff we are doing. No, it does not. You are attacking a strawman here, one where I obviously (and usually quiet aggressively) agree with your point. My argument was that it is hardly possible to gain a sufficient understanding of many protocols to be able to thoroughly design network measurements while accounting for all possible harms within the time available for a PhD. That is just as much a recipe for disaster as it is a practical reality for many people out there; Start your PhD, do four papers in four years, and have your first one submitted by the end of year 1. Learning by doing, breaking too much in the meantime, which is not a desirable state of affairs, especially given that with the standard-academia-workload no PI will be able to thoroughly vet what their students built. To still be able to make a positive difference, I started my current efforts to build something to curb this issue; Because no matter if one extends sympathies to people doing harm out of ignorance (no matter whether you see the cause for that in an underlying system or not), the truth is also that those measurements will keep hitting the Internet. I might have a bit too much of an idealistic world view here, but I believe established infrastructure which provides proper feedback from more experienced people before packets hit the fan (to which one can also point people to if they make mistakes) can really make a positive difference here, especially if people who really know what they are doing are willing to look at things before they are let out on the Internet. Talking of which: John, would you be willing to be part of something like that? I mean, it will probably take quiet some time until I have this going, so this would be a commitment for an undetermined future point in time (mostly due to me not having a /23 v4 spare for the project; But I am working on it. And of course then there is the adoption thing.)... But I believe your eyes in such a project might actually allow quiet a lot of students to learn a lot. With best regards, Tobias ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF (and other email security protocols) Survey
It appears that Tobias Fiebig via mailop said: >Yes, I do, see Footnote ** of my previous mail; But to recap: It is a complex >problem between how academia is setup, what it incentivizes, what >it requires, what it rewards, and who does network measurement research >(usually people without operational experience working on things technically >too big for a single PhD). So if they were competemnt and ethical, tney would stop and find people to work with who understand the issues so they can do research that is not abusive and could have useful results. Unfortunately, as we have seen, they are neither. Having spent my entire life in and around academia, I have no sympathy for people who say that since we are so nice and our goals are virtuous it excuses the stuff we are doing. No, it does not. R's, John ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF (and other email security protocols) Survey
Hey Bill, > Do you know why his students have at least twice in the past engaged in > deceptive spamming to gather data? Yes, I do, see Footnote ** of my previous mail; But to recap: It is a complex problem between how academia is setup, what it incentivizes, what it requires, what it rewards, and who does network measurement research (usually people without operational experience working on things technically too big for a single PhD). You can, of course, now simply tie that to Tijay, who at least starts to engage with the issue now, and tries to be part of a solution instead of the problem; Then again, as I said, it is a wider problem, and there surely is a ton more science-y-groups that are doing similar things, but simply did not pop up on your radar yet. I for one personally prefer working on fixing the underlying problem instead of keeping beating on a person that is actually developing awareness of the issue. Because academia will not go away. PhDs doing research won't. So,... well. Let's fix things instead. > Frankly, there's no chance that I'll ever cooperate with that person's > research. This is fine. Your choice, and also the reason I am trying to build one stable AS for that kind of research, so people can easily enforce never being involved on multiple network layers, without running the risk of, e.g., blocking IPs that are later used by a different entity (when using stuff like EC2, for example). Similarly, that's the reason why such an entity should have a board checking planned research that actually involves non-academics. In the end, well done research can be really beneficial (e.g., by figuring out changes to RFCs); It just MUST not cause harm, and that harm is often not apparent, certainly not to people usually found in IRBs, and often not even for people that are not actively involved in that _specific_ type of system (Say, DNSOP assessing Mail measurements, or MAILOP commenting on some BGP experiments, even though, of course, there are community overlaps). > His tenure should be pulled. He has a pattern demonstrating ignorance of his > field of study. This is not fine; At least in my personal opinion. It is essentially what I talked about in my previous mail when referring to rather frustrated comments that do not necessarily take into account that the person on the other end of the communication is also a, well, person. Furthermore, it--again--does not really help in mitigating the underlying problem, which is a bit bigger than just one person doing research, but instead may even make it worse. I would usually have this discussion off-list, but given that you posted this to the list as well, it might be worthwhile to talk about it somewhat openly, as it relates to how we want to interact with each other here. The reason I believe that comment is not fine is that it rather directly attacks Tijay as a person, without considering the context of events. Your earlier statements in that context were even a bit stronger. In any case, this is certainly not in line with how I would expect a rather senior engineer to communicate, especially given that this message may also be read by more junior people directly. In the end, we are all shaping the tone in the community. Specifically, your call for revoking tenure is relatively close to "make that person lose their job and prevent them from ever working in that field again". This is usually done when people demonstrate significant neglect of ethical standards and practices in their _academic field_.* The problem here, though, as I mentioned above are those standards and practices (or rather: Especially the incentive structures and requirements) in the field, which are just incompatible with how the Internet works (and this issue is certainly not restricted to mail). So, you are basically putting a lot of (kind of justified) frustration at academic research at large into comments towards a single person. Furthermore, when I think about the impact of one of the measurement studies (crashing MXes of smaller ops running off-the-shelf frameworks), I cannot shake off the feeling that a reply to one of those operators posting to mailop asking for help with the issue (without the measurements having been tied to Tijay) could very well have been: "Ah, yeah. Unethical scans. But you should have figured that out by yourself. Maybe, if you can't debug something that simple, and figure out how to block it, you shouldn't be running mail-servers on the Internet. *shrug*" Which, I think, illustrates the point about tone I hinted at earlier a bit more. Instead, I would expect clear, yet respectful, communication that takes the underlying problem into account and works towards a solution, making sure that the problem does not occur again in the future, independent from the people involved, while the people involved are allowed to grow. But that may just be me. With best regards, Tobias *
Re: [mailop] SPF (and other email security protocols) Survey
Dňa 23. novembra 2022 14:32:51 UTC používateľ "Taejoong (tijay) Chung via mailop" napísal: >Yes. As Tobias explained, we can observe certain phenomena (e.g., some mail >servers look up SPF records more than 100 times) from data, but we don't >know *why* it happens; we have interviewed around 5~10 mail operators >individually, which were great but hard to scale, thus we thought that >survey would be useful. Nobody maintaining own mail service will have troubles with limit 10. My SPF record, for example requires only 1 DNS lookup (record itself), as it contains only IP addresses. If someone have problem with that limit (10), he must take into account, that rising this limit will increase used resources on receiving side and i have feel, thet they do not care, as count of DNS lookups is not something, what bother sending side... Consider, that 10 DNS lookups on 1 000 messages can be 10 000 DNS lookups. And what those who are receiving millions messages or more? Sure, plain DNS lookups are cheap, especially with local cache -- until someone "smart" will not set 60s TTL for these records. And i afraid, that exactly these, who have problem with current limit, will be "smart". And with DNSSEC the DNS lookups are not cheap anymore, or more precise the validation is not cheap. Anyway, using SPF on shared environment is something, what negates SPF purpose at all, as anyone from that shared provider can succesfuly pass SPF for any other domain in it (sharing the same TXT records). Thus in these shared services is SPF mostly cosmetic or part of PR/marketing only. Whole result then depends only on that, if particular provider checks spoofing from own customers, which is a) not published and b) moves trust to smewhere else. regards -- Slavko https://www.slavino.sk/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF (and other email security protocols) Survey
> own fault if you system breaks due to your inexperience (RTFM etc.)... and > well, there is a lot of noise on the net, and my own stuff was hit by > something similar recently [0]; So... bigger discussion again, I'd argue. > > Again, what is 'the science of security' may very well be the most > debated topic in that scientific community. Happy to discuss that if we > cross paths at RIPE/NANOG/IETF or sth. somewhen. > > * I mean, how else should you take consent? You can decide at every > step of the process. If the questions were presented along with the consent > request, they would be presented without collecting consent to present the > questions, which kind of defeats the point of consent in the first place. > > [0] > https://doing-stupid-things.as59645.net/mail/opensmtpd/mysql/2022/08/30/receiving-an-email.html > > > -Original Message- > From: mailop On Behalf Of Alessandro Vesely > via mailop > Sent: Wednesday, 23 November 2022 12:17 > To: mailop@mailop.org > Cc: ti...@vt.edu > Subject: Re: [mailop] SPF (and other email security protocols) Survey > > On Tue 22/Nov/2022 16:41:44 +0100 Todd Herr via mailop wrote: > > On Mon, Nov 21, 2022 at 2:00 PM Taejoong (tijay) Chung via mailop wrote: > >> > >> The Sender Policy Framework (SPF) is an easy way to check whether the > >> sender is authorized to send emails – however, it may cause some > >> security holes if it causes too many DNS lookups. > >> > >> Together with researchers from Virginia Tech and Max-Planck-Institut > >> für Informatik, we would like to understand which challenges > >> operators face when configuring the proper limit of DNS queries for > >> SPF lookups and when deploying other email security protocols. > > > > I'm not quite sure I understand the premise behind the survey, and > > since I don't manage email for any domain, I can't realistically take > > part in the survey to learn the premise, so I'll try here. > > > > The proper limit of DNS queries for SPF lookups is ten, per RFC 7208, > > and > > *should* be baked into any code library used by an operator that is > > doing SPF validation on inbound mail, so I don't see them facing > challenges here. > > > On my MTA the (default) limit is 20. That looks consistent with Postel's > principle. > > > > On the other hand, staying under the limit of ten for domains publishing > > SPF records can be quite a challenge for complex organizations using > > multiple services to send their email, and while there are known ways to > > skin that cat, there isn't a universally adopted method for doing so. > > > > Is the survey investigating problems faced by operators doing SPF > > validation or operators publishing SPF records or both? > > > While we wait for Tijay's reply, let me anticipate that he works on a > "DNSSECFixer" project, which leverages machine learning techniques to > automatically fix incorrectly configured and insecure domains.[*] > > As one of the few who took part in the survey, my guess is that it aims at > a > bird's eye view of email operators' involvement in the configuration of > security features available in SMTP servers. Correct? > > As the survey asks for the domain name where such features are configured, > I > understand that that might sound as intelligence gathering for a targeted > attack. However, I don't reckon the survey collects any sensitive data. > > > Best > Ale > -- > > [*] https://cs.vt.edu/research/research-areas/security.html > > > > > > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop > > ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF (and other email security protocols) Survey
submission. Certainly people that haven't run their own mailserver/authNSes for more than a decade. Yes, recipe for disaster. Currently, I am actually looking into building an 'AS for Measurement Research', especially 'higher level protocols' (mail, DNS,... ) that is open to researchers; That should a) have its own ASN, /47, /23, and delegated zones, so people can _really_ easily block/filter it, b) Maintain a global opt-out list across experiments, c) Have an 'Internet measurement ethics board' that vets experiments before they are run, so that they are checked for possible harm and correctness of implementation, and d) Have somewhat experienced people run 24/7 abuse, so _when_ things go wrong, stuff is mitigated quickly. Hence, it would make measurement more accessible (not all [smaller] universities have the infrastructure in place to do proper active measurements), while also having mechanics in place to make sure 'opsies' due to inexperience (which, tbh, quiet commonly come out of the science bobble [I am also part of]) do not have as much impact. But I am currently stuck at 'getting a /23', which is surprisingly difficult without $30k to blow... so if one of you has some spare v4, I wouldn't say no. ;-) *** There were a lot of unkind words around that here; Then again, it is probably the same voices that are also quick to proclaim that it is your own fault if you system breaks due to your inexperience (RTFM etc.)... and well, there is a lot of noise on the net, and my own stuff was hit by something similar recently [0]; So... bigger discussion again, I'd argue. Again, what is 'the science of security' may very well be the most debated topic in that scientific community. Happy to discuss that if we cross paths at RIPE/NANOG/IETF or sth. somewhen. * I mean, how else should you take consent? You can decide at every step of the process. If the questions were presented along with the consent request, they would be presented without collecting consent to present the questions, which kind of defeats the point of consent in the first place. [0] https://doing-stupid-things.as59645.net/mail/opensmtpd/mysql/2022/08/30/receiving-an-email.html -Original Message- From: mailop On Behalf Of Alessandro Vesely via mailop Sent: Wednesday, 23 November 2022 12:17 To: mailop@mailop.org Cc: ti...@vt.edu Subject: Re: [mailop] SPF (and other email security protocols) Survey On Tue 22/Nov/2022 16:41:44 +0100 Todd Herr via mailop wrote: On Mon, Nov 21, 2022 at 2:00 PM Taejoong (tijay) Chung via mailop wrote: The Sender Policy Framework (SPF) is an easy way to check whether the sender is authorized to send emails – however, it may cause some security holes if it causes too many DNS lookups. Together with researchers from Virginia Tech and Max-Planck-Institut für Informatik, we would like to understand which challenges operators face when configuring the proper limit of DNS queries for SPF lookups and when deploying other email security protocols. I'm not quite sure I understand the premise behind the survey, and since I don't manage email for any domain, I can't realistically take part in the survey to learn the premise, so I'll try here. The proper limit of DNS queries for SPF lookups is ten, per RFC 7208, and *should* be baked into any code library used by an operator that is doing SPF validation on inbound mail, so I don't see them facing challenges here. On my MTA the (default) limit is 20. That looks consistent with Postel's principle. On the other hand, staying under the limit of ten for domains publishing SPF records can be quite a challenge for complex organizations using multiple services to send their email, and while there are known ways to skin that cat, there isn't a universally adopted method for doing so. Is the survey investigating problems faced by operators doing SPF validation or operators publishing SPF records or both? While we wait for Tijay's reply, let me anticipate that he works on a "DNSSECFixer" project, which leverages machine learning techniques to automatically fix incorrectly configured and insecure domains.[*] As one of the few who took part in the survey, my guess is that it aims at a bird's eye view of email operators' involvement in the configuration of security features available in SMTP servers. Correct? As the survey asks for the domain name where such features are configured, I understand that that might sound as intelligence gathering for a targeted attack. However, I don't reckon the survey collects any sensitive data. Best Ale -- [*] https://cs.vt.edu/research/research-areas/security.html ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop -- Bill Cole b...@scc
Re: [mailop] SPF (and other email security protocols) Survey
-out list across experiments, c) Have an 'Internet measurement ethics board' that vets experiments before they are run, so that they are checked for possible harm and correctness of implementation, and d) Have somewhat experienced people run 24/7 abuse, so _when_ things go wrong, stuff is mitigated quickly. Hence, it would make measurement more accessible (not all [smaller] universities have the infrastructure in place to do proper active measurements), while also having mechanics in place to make sure 'opsies' due to inexperience (which, tbh, quiet commonly come out of the science bobble [I am also part of]) do not have as much impact. But I am currently stuck at 'getting a /23', which is surprisingly difficult without $30k to blow... so if one of you has some spare v4, I wouldn't say no. ;-) *** There were a lot of unkind words around that here; Then again, it is probably the same voices that are also quick to proclaim that it is your own fault if you system breaks due to your inexperience (RTFM etc.)... and well, there is a lot of noise on the net, and my own stuff was hit by something similar recently [0]; So... bigger discussion again, I'd argue. Again, what is 'the science of security' may very well be the most debated topic in that scientific community. Happy to discuss that if we cross paths at RIPE/NANOG/IETF or sth. somewhen. * I mean, how else should you take consent? You can decide at every step of the process. If the questions were presented along with the consent request, they would be presented without collecting consent to present the questions, which kind of defeats the point of consent in the first place. [0] https://doing-stupid-things.as59645.net/mail/opensmtpd/mysql/2022/08/30/receiving-an-email.html -Original Message- From: mailop On Behalf Of Alessandro Vesely via mailop Sent: Wednesday, 23 November 2022 12:17 To: mailop@mailop.org Cc: ti...@vt.edu Subject: Re: [mailop] SPF (and other email security protocols) Survey On Tue 22/Nov/2022 16:41:44 +0100 Todd Herr via mailop wrote: > On Mon, Nov 21, 2022 at 2:00 PM Taejoong (tijay) Chung via mailop wrote: >> >> The Sender Policy Framework (SPF) is an easy way to check whether the >> sender is authorized to send emails – however, it may cause some >> security holes if it causes too many DNS lookups. >> >> Together with researchers from Virginia Tech and Max-Planck-Institut >> für Informatik, we would like to understand which challenges >> operators face when configuring the proper limit of DNS queries for >> SPF lookups and when deploying other email security protocols. > > I'm not quite sure I understand the premise behind the survey, and > since I don't manage email for any domain, I can't realistically take > part in the survey to learn the premise, so I'll try here. > > The proper limit of DNS queries for SPF lookups is ten, per RFC 7208, > and > *should* be baked into any code library used by an operator that is > doing SPF validation on inbound mail, so I don't see them facing challenges > here. On my MTA the (default) limit is 20. That looks consistent with Postel's principle. > On the other hand, staying under the limit of ten for domains publishing > SPF records can be quite a challenge for complex organizations using > multiple services to send their email, and while there are known ways to > skin that cat, there isn't a universally adopted method for doing so. > > Is the survey investigating problems faced by operators doing SPF > validation or operators publishing SPF records or both? While we wait for Tijay's reply, let me anticipate that he works on a "DNSSECFixer" project, which leverages machine learning techniques to automatically fix incorrectly configured and insecure domains.[*] As one of the few who took part in the survey, my guess is that it aims at a bird's eye view of email operators' involvement in the configuration of security features available in SMTP servers. Correct? As the survey asks for the domain name where such features are configured, I understand that that might sound as intelligence gathering for a targeted attack. However, I don't reckon the survey collects any sensitive data. Best Ale -- [*] https://cs.vt.edu/research/research-areas/security.html ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF (and other email security protocols) Survey
On Tue 22/Nov/2022 16:41:44 +0100 Todd Herr via mailop wrote: On Mon, Nov 21, 2022 at 2:00 PM Taejoong (tijay) Chung via mailop wrote: The Sender Policy Framework (SPF) is an easy way to check whether the sender is authorized to send emails – however, it may cause some security holes if it causes too many DNS lookups. Together with researchers from Virginia Tech and Max-Planck-Institut für Informatik, we would like to understand which challenges operators face when configuring the proper limit of DNS queries for SPF lookups and when deploying other email security protocols. I'm not quite sure I understand the premise behind the survey, and since I don't manage email for any domain, I can't realistically take part in the survey to learn the premise, so I'll try here. The proper limit of DNS queries for SPF lookups is ten, per RFC 7208, and *should* be baked into any code library used by an operator that is doing SPF validation on inbound mail, so I don't see them facing challenges here. On my MTA the (default) limit is 20. That looks consistent with Postel's principle. On the other hand, staying under the limit of ten for domains publishing SPF records can be quite a challenge for complex organizations using multiple services to send their email, and while there are known ways to skin that cat, there isn't a universally adopted method for doing so. Is the survey investigating problems faced by operators doing SPF validation or operators publishing SPF records or both? While we wait for Tijay's reply, let me anticipate that he works on a "DNSSECFixer" project, which leverages machine learning techniques to automatically fix incorrectly configured and insecure domains.[*] As one of the few who took part in the survey, my guess is that it aims at a bird's eye view of email operators' involvement in the configuration of security features available in SMTP servers. Correct? As the survey asks for the domain name where such features are configured, I understand that that might sound as intelligence gathering for a targeted attack. However, I don't reckon the survey collects any sensitive data. Best Ale -- [*] https://cs.vt.edu/research/research-areas/security.html ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF (and other email security protocols) Survey
On Mon, Nov 21, 2022 at 2:00 PM Taejoong (tijay) Chung via mailop < mailop@mailop.org> wrote: > Greetings, > > The Sender Policy Framework (SPF) is an easy way to check whether the > sender is authorized to send emails – however, it may cause some security > holes if it causes too many DNS lookups. > > Together with researchers from Virginia Tech and Max-Planck-Institut für > Informatik, we would like to understand which challenges operators face > when configuring the proper limit of DNS queries for SPF lookups and when > deploying other email security protocols. > > > I'm not quite sure I understand the premise behind the survey, and since I don't manage email for any domain, I can't realistically take part in the survey to learn the premise, so I'll try here. The proper limit of DNS queries for SPF lookups is ten, per RFC 7208, and *should* be baked into any code library used by an operator that is doing SPF validation on inbound mail, so I don't see them facing challenges here. On the other hand, staying under the limit of ten for domains publishing SPF records can be quite a challenge for complex organizations using multiple services to send their email, and while there are known ways to skin that cat, there isn't a universally adopted method for doing so. Is the survey investigating problems faced by operators doing SPF validation or operators publishing SPF records or both? -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.h...@valimail.com *m:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF (and other email security protocols) Survey
On Tue 22/Nov/2022 02:17:14 +0100 L. Mark Stone via mailop wrote: IMHO, asking me to grant rights before I know to what it is that I am granting rights is, at best, not nice. What right(s) did you (omit to) grant? The first page questions were about consent to participate and understanding the nature of the survey. Best Ale -- ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF (and other email security protocols) Survey
On Nov 21, 2022, at 7:45 PM, Stuart Henderson via mailop wrote: > > On 2022/11/21 13:55, Taejoong (tijay) Chung via mailop wrote: >> Please note that we do NOT collect any personal information, thus >> the Institutional Review Board (IRB) at Virginia Tech determined the >> survey as Non-Human Subjects Research. > > eh, that doesn't make any kind of sense. Do you know what an IRB is and what their role is? While the terminology may be not what I’d choose the underlying message is: - This research project has been reviewed by the appropriate panel at the research institution; - This research project has been determined not to be performing research that can harm people and/of collect clinical data about them as individuals that can be tied directly to them; - This research project is not subject to the more extensive rules and regulations related to human research. If you’d like to discuss the form of the warning and the wording specifically, I’m sure there are fora hosted by the various government agencies and oversight organizations that you can join to tell them their wording is confusing. Finding those fora is left as an exercise for the reader. Laura ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF (and other email security protocols) Survey
The survey does ask for domains and other specific identifying information (optionally , to be fair) -- but only after the very first page which asks the user to grant usage rights without even knowing the questions about to be asked. (Only "Yes" is an allowed, mandatory answer.) I'll leave it to the lawyers to debate the ethics/legality. IMHO, asking me to grant rights before I know to what it is that I am granting rights is, at best, not nice. Best regards to all, Mark _ L. Mark Stone, Founder North America's Leading Zimbra VAR/BSP/Training Partner For Companies With Mission-Critical Email Needs - Original Message - From: "Sebastian Nielsen via mailop" To: "Mailing List" Sent: Monday, November 21, 2022 5:49:15 PM Subject: Re: [mailop] SPF (and other email security protocols) Survey It DO make sense. What it means, is that the subject of the survey, is non human (is not about humans) and thus does not require any approval. Surveys that run a specific sensitive subject, must in some places, have a license or approval first. For example, these are non-human: "Do you run windows at home?" "Which car-brand do you drive?" "Whats the brand of the PC you are using?" But those 3 examples are human and may require a approval: "Do you use sunblocker when sunbathing?" "Which is your primary religion?" "Which size of clothes do you buy?" -Ursprungligt meddelande- Från: Stuart Henderson via mailop Skickat: den 21 november 2022 20:38 Till: Taejoong (tijay) Chung Kopia: mailop@mailop.org Ämne: Re: [mailop] SPF (and other email security protocols) Survey On 2022/11/21 13:55, Taejoong (tijay) Chung via mailop wrote: > Please note that we do NOT collect any personal information, thus the > Institutional Review Board (IRB) at Virginia Tech determined the > survey as Non-Human Subjects Research. eh, that doesn't make any kind of sense. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF (and other email security protocols) Survey
It DO make sense. What it means, is that the subject of the survey, is non human (is not about humans) and thus does not require any approval. Surveys that run a specific sensitive subject, must in some places, have a license or approval first. For example, these are non-human: "Do you run windows at home?" "Which car-brand do you drive?" "Whats the brand of the PC you are using?" But those 3 examples are human and may require a approval: "Do you use sunblocker when sunbathing?" "Which is your primary religion?" "Which size of clothes do you buy?" -Ursprungligt meddelande- Från: Stuart Henderson via mailop Skickat: den 21 november 2022 20:38 Till: Taejoong (tijay) Chung Kopia: mailop@mailop.org Ämne: Re: [mailop] SPF (and other email security protocols) Survey On 2022/11/21 13:55, Taejoong (tijay) Chung via mailop wrote: > Please note that we do NOT collect any personal information, thus the > Institutional Review Board (IRB) at Virginia Tech determined the > survey as Non-Human Subjects Research. eh, that doesn't make any kind of sense. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF (and other email security protocols) Survey
It appears that Stuart Henderson via mailop said: >On 2022/11/21 13:55, Taejoong (tijay) Chung via mailop wrote: >> Please note that we do NOT collect any personal information, thus >> the Institutional Review Board (IRB) at Virginia Tech determined the >> survey as Non-Human Subjects Research. > >eh, that doesn't make any kind of sense. IRBs seem to believe that servers are run by robots, not people, and those robots fill out the surveys. I would stay far away from surveys like this. R's, John ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] SPF (and other email security protocols) Survey
On 2022/11/21 13:55, Taejoong (tijay) Chung via mailop wrote: > Please note that we do NOT collect any personal information, thus > the Institutional Review Board (IRB) at Virginia Tech determined the > survey as Non-Human Subjects Research. eh, that doesn't make any kind of sense. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
