<html>

  <head>

    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    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 <u>recognized</u>

    sandbox sites or -- much better -- to an openssl-operated one.<br>

    <br>

    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.<br>

    <br>

    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.<br>

    <br>

    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.<br>

    <pre class="moz-signature" cols="80">--

Thank you,

Johann v. Preußen

<b>original anchor description (100% of the message content):</b>

Attn:__here__is__your___$lâââ__FacebÏÏk__giftcard.

__WÎµ__NÎµÎµd__YÏÎ¼r__ShiÏmeÎ·t__InfÏrmatiÏÎ·s__

Click_Here

</pre>

    <div class="moz-cite-prefix">On 2016.Apr.04 09:08, Jeffrey Walton

      wrote:<br>

    </div>

    <blockquote

cite="mid:CAH8yC8kQ0J1vxmFNLYGrNRtamv5rY1+ONePnAAnV_o+6ke-_UQ@mail.gmail.com"

      type="cite">

      <blockquote type="cite">

        <pre wrap="">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.

</pre>

      </blockquote>

      <pre wrap="">

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

</pre>

    </blockquote>

    <br>

  </body>

</html>