i am not certain i understand how it is google's fault that this owenevans98|Dawn was able to slip into the listserv database. this is, of course, assuming that this was not done via a simple sign-up. i also do not understand how prohibiting a posting (content, infra) that obfuscates a message within a host of symbols with a net zero percent of prose and 100% anchor description is responding to some sort of a "fad". this list is re problems and solutions that can only be conveyed in prose ... no prose == no message. and permitting private anchors is also a questionable security practice. it does not seem unreasonable to require anchors to be to _recognized_ sandbox sites or -- much better -- to an openssl-operated one. moreover, as i pointed out in a pm to Steve, this is a real security issue for openssl's list in that such a breach (if it is one) opens the names and email contact info of a broad range of security-responsible people that will invariably include some in the upper regions of the perm chain. these people are the very people that are targeted by malicious attempts (and some startling successes) to breach much more than an organization's email system. yes, this person has seemingly stopped with postings, but i am hearing no assurance that they have even been eliminated from the subscription database. just being able to listen will garner a wealth of sensitive info obtainable re a most desirable crowd of people/victims. even the most simplistic listserv app has the ability to withhold subscriber email addr's and still provide a secure pm capability. now that it is apparent|perceived that the list is vulnerable, i believe the prudent route to go is to keep those addr's and subscriber real-world names out of the "limelight". i see no reason why a sanitized subscriber profile available from a link within the person's public handle would not be adequate for identification purposes and would actually become an enhancement to the listserv app's usefulness to subscribers. this would certainly shield the subscriber in a reliably meaningful way, serve to protect a subscriber's own email system, and enhance the security of openssl's own listserv ops. -- Thank you, Johann v. Preu?en *original anchor description (100% of the message content):* Attn:__here__is__your___$l?? ?? ?? __Faceb????k__giftcard. __W??__N????d__Y????r__Shi??me??t__Inf??rmati????s__ Click_Here On 2016.Apr.04 09:08, Jeffrey Walton wrote: >> And anyway, this seems to be a case where the genuine >> operator of an e-mail domain is failing to correctly >> authenticate submissions by their own users, which no >> amount of 3rd party automation (other than blacklisting >> the failing provider, in this case gmail) could stop. > Yeah, I'm guessing there was a vulnerability in one of the other > Google services, and that Google service was allowed to make web-based > email submissions on behalf of the user. Classic injection and failure > to validate sessions or parameters... > > I'm also guessing Google fixed it because it has stopped. > > Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160404/0de1ecea/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3825 bytes Desc: S/MIME Cryptographic Signature URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160404/0de1ecea/attachment.bin>
