Re: [openssl-users] Fwd: CONGRATULATION____REF#87670

[PGNet Dev]

Is there nowhere else this interminable thread can be taken?  Some of us 
actually subscribe to this list to actually follow *openssl* use & issues.


Take it up with the list admins directly?

On 04/04/2016 05:39 PM, Jakob Bohm wrote:

On 05/04/2016 01:47, Johann v. Preußen wrote:

'/No one (until about 2 hours ago) were discussing how the //
//particular "From" address got past the "you must be //
//subscribed to post" filter/'
actually, i first posted on this issue c. 76 hours ago.



Not in this thread on openssl-users as far as I can tell.



'/maybe the spoofed From address happened to be a subscriber/'
is it possible that openssl still does not know if the email addr is a
real subscriber?



I have no way of knowing since I am not one of the list admins.


'/maybe there is a bug in the list management software or configuration/'
yes, i surely hope someone is looking into this possibility.

further, not only was owenevans98 able to post an original message (the
subject of this thread), but there was a subsequent posting in reply to
another thread. thus, the conclusion that owenevans98 was not only able
to post but was|is receiving the listserv mailings is self-evident. the
fact that this two-way comm path came into existence means that the
listserv database was corrupted and that the original posting was not
some slip-up in permitting an un-authorized one-time posting.


Which other thread was that?



jakob, i appreciate your taking of the time to detail some of openssl's
listserv practices and view-points. perhaps it is best to set forth the
synopses of my views:


I am not a list admin or other official team member, I am just an
active list member who wants to avoid the list admins following bad
advice from people like you and Ben Humpert.



 1. make certain ' owenevans98' and any other illegitimate posters are
not receiving listserv mailings;


Question is if owenevans97 is an illegitimate poster or a legitimate
poster whose e-mail address was spoofed.

Anyway, the OpenSSL mailings are all being indexed on the world wide
web by multiple organizations, where anyone can read them.


 2. stop publishing the subscriber's protected PII in the clear; and


Again, I see no sign this is happening other than the age-old inclusion
of original from and reply addresses in postings (which is limited to
those who post, and doesn't affect those who only subscribe).


 3. control postings of anchors.



I disagree.  A number of e-mail clients (MUAs) automatically turn
textual URLs into anchors and make it very difficult (if not
impossible) for the posting user to avoid this.  And people
professional enough to understand most of the stuff on OpenSSL mailing
list also know not to click on links in strange e-mails and forum posts.



according to your comment quoted, supra, it seems that the step
indicated in Item 1 has yet to be taken.


I wouldn't know.



Item 2 can be implemented by inaugurating a subscriber-managed profile
and merely publishing a user handle linked thereto. thus, you can shift
the onus to the subscriber to reveal whatever info they wish rather than
arbitrarily exposing to the world a subscriber's personal name, email
addr, and work-force association.


Did you read and understand any of that which I wrote, or
are you just trolling?



in the case of Item 3, i understand all of the reasons for having links
(not html anchors) in postings. it is a very minor inconvenience for
someone who has  a burning interest in viewing a link to copy the
clear-text link into a browser versus clicking on an anchor description
which could lead the subscriber far astray from what the description
says. it also enhances the subscriber experience to visually see where
the link is going instead of having the actual target obscured by a
description that may be deceptive, merely misleading, or non-apparent
(i.e., 'click here').

jakob, you also mention concern re MTA operators having some issues with
changes you may make to the listserv ops. please note: none of the three
(3) items, supra, i have suggested have any impact on other MTA
operators as they are totally internal-control enhancement proc's.


I am an MTA operator, I am not a listserv op.  I was posting concerns I
have as an MTA operator and list member with stupid changes suggested
by you and Ben Humpert.



i cannot understand why openssl's filtering missed the fact that the
posting that is subject of this thread predominated in symbols and
control characters, contained no actual message text, and still went
through. hopefully, someone is also looking into why this happened.



Did you read the brief but very clear message posted on 2016-04-02
15:24 UTC by Rich Salz (who is an OpenSSL team member and may have
access to the listserv configuration details not published to avoid
helping spammers)?


P.S.

Please don't CC list members on replies to the list, it causes
duplicate copies to reach them (since list membership is required to
post to the list 

Re: [openssl-users] Fwd: CONGRATULATION____REF#87670

[Jakob Bohm]

On 05/04/2016 01:47, Johann v. Preußen wrote:

'/No one (until about 2 hours ago) were discussing how the //
//particular "From" address got past the "you must be //
//subscribed to post" filter/'
actually, i first posted on this issue c. 76 hours ago.



Not in this thread on openssl-users as far as I can tell.



'/maybe the spoofed From address happened to be a subscriber/'
is it possible that openssl still does not know if the email addr is a
real subscriber?



I have no way of knowing since I am not one of the list admins.


'/maybe there is a bug in the list management software or configuration/'
yes, i surely hope someone is looking into this possibility.

further, not only was owenevans98 able to post an original message (the
subject of this thread), but there was a subsequent posting in reply to
another thread. thus, the conclusion that owenevans98 was not only able
to post but was|is receiving the listserv mailings is self-evident. the
fact that this two-way comm path came into existence means that the
listserv database was corrupted and that the original posting was not
some slip-up in permitting an un-authorized one-time posting.


Which other thread was that?



jakob, i appreciate your taking of the time to detail some of openssl's
listserv practices and view-points. perhaps it is best to set forth the
synopses of my views:


I am not a list admin or other official team member, I am just an
active list member who wants to avoid the list admins following bad
advice from people like you and Ben Humpert.



 1. make certain ' owenevans98' and any other illegitimate posters are
not receiving listserv mailings;


Question is if owenevans97 is an illegitimate poster or a legitimate
poster whose e-mail address was spoofed.

Anyway, the OpenSSL mailings are all being indexed on the world wide
web by multiple organizations, where anyone can read them.


 2. stop publishing the subscriber's protected PII in the clear; and


Again, I see no sign this is happening other than the age-old inclusion
of original from and reply addresses in postings (which is limited to
those who post, and doesn't affect those who only subscribe).


 3. control postings of anchors.



I disagree.  A number of e-mail clients (MUAs) automatically turn
textual URLs into anchors and make it very difficult (if not
impossible) for the posting user to avoid this.  And people
professional enough to understand most of the stuff on OpenSSL mailing
list also know not to click on links in strange e-mails and forum posts.



according to your comment quoted, supra, it seems that the step
indicated in Item 1 has yet to be taken.


I wouldn't know.



Item 2 can be implemented by inaugurating a subscriber-managed profile
and merely publishing a user handle linked thereto. thus, you can shift
the onus to the subscriber to reveal whatever info they wish rather than
arbitrarily exposing to the world a subscriber's personal name, email
addr, and work-force association.


Did you read and understand any of that which I wrote, or
are you just trolling?



in the case of Item 3, i understand all of the reasons for having links
(not html anchors) in postings. it is a very minor inconvenience for
someone who has  a burning interest in viewing a link to copy the
clear-text link into a browser versus clicking on an anchor description
which could lead the subscriber far astray from what the description
says. it also enhances the subscriber experience to visually see where
the link is going instead of having the actual target obscured by a
description that may be deceptive, merely misleading, or non-apparent
(i.e., 'click here').

jakob, you also mention concern re MTA operators having some issues with
changes you may make to the listserv ops. please note: none of the three
(3) items, supra, i have suggested have any impact on other MTA
operators as they are totally internal-control enhancement proc's.


I am an MTA operator, I am not a listserv op.  I was posting concerns I
have as an MTA operator and list member with stupid changes suggested
by you and Ben Humpert.



i cannot understand why openssl's filtering missed the fact that the
posting that is subject of this thread predominated in symbols and
control characters, contained no actual message text, and still went
through. hopefully, someone is also looking into why this happened.



Did you read the brief but very clear message posted on 2016-04-02
15:24 UTC by Rich Salz (who is an OpenSSL team member and may have
access to the listserv configuration details not published to avoid
helping spammers)?


P.S.

Please don't CC list members on replies to the list, it causes
duplicate copies to reach them (since list membership is required to
post to the list anyway).



On 2016.Apr.04 15:36, Jakob Bohm wrote:

On 04/04/2016 22:28, Johann v. Preußen wrote:

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 

Re: [openssl-users] Fwd: CONGRATULATION____REF#87670

[Johann v . Preußen]

'/No one (until about 2 hours ago) were discussing how the //
//particular "From" address got past the "you must be //
//subscribed to post" filter/'
actually, i first posted on this issue c. 76 hours ago.

'/maybe the spoofed From address happened to be a subscriber/'
is it possible that openssl still does not know if the email addr is a real 
subscriber?


'/maybe there is a bug in the list management software or configuration/'
yes, i surely hope someone is looking into this possibility.

further, not only was owenevans98 able to post an original message (the subject 
of this thread), but there was a subsequent posting in reply to another thread. 
thus, the conclusion that owenevans98 was not only able to post but was|is 
receiving the listserv mailings is self-evident. the fact that this two-way comm 
path came into existence means that the listserv database was corrupted and that 
the original posting was not some slip-up in permitting an un-authorized 
one-time posting.


jakob, i appreciate your taking of the time to detail some of openssl's listserv 
practices and view-points. perhaps it is best to set forth the synopses of my views:


1. make certain ' owenevans98' and any other illegitimate posters are not
   receiving listserv mailings;
2. stop publishing the subscriber's protected PII in the clear; and
3. control postings of anchors.

according to your comment quoted, supra, it seems that the step indicated in 
Item 1 has yet to be taken.


Item 2 can be implemented by inaugurating a subscriber-managed profile and 
merely publishing a user handle linked thereto. thus, you can shift the onus to 
the subscriber to reveal whatever info they wish rather than arbitrarily 
exposing to the world a subscriber's personal name, email addr, and work-force 
association.


in the case of Item 3, i understand all of the reasons for having links (not 
html anchors) in postings. it is a very minor inconvenience for someone who has  
a burning interest in viewing a link to copy the clear-text link into a browser 
versus clicking on an anchor description which could lead the subscriber far 
astray from what the description says. it also enhances the subscriber 
experience to visually see where the link is going instead of having the actual 
target obscured by a description that may be deceptive, merely misleading, or 
non-apparent (i.e., 'click here').


jakob, you also mention concern re MTA operators having some issues with changes 
you may make to the listserv ops. please note: none of the three (3) items, 
supra, i have suggested have any impact on other MTA operators as they are 
totally internal-control enhancement proc's.


i cannot understand why openssl's filtering missed the fact that the posting 
that is subject of this thread predominated in symbols and control characters, 
contained no actual message text, and still went through. hopefully, someone is 
also looking into why this happened.


--
Thank you,

Johann v. Preußen

On 2016.Apr.04 15:36, Jakob Bohm wrote:

On 04/04/2016 22:28, Johann v. Preußen wrote:
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.



No one (until about 2 hours ago) were discussing how the
particular "From" address got past the "you must be
subscribed to post" filter, maybe the spoofed From address
happened to be a subscriber, maybe there is a bug in the
list management software or configuration.

There was discussion of which generic "hard-reject" filters
should be applied and someone suggested prematurely
applying a number of recently "trendy" such rules promoted
by (ironically in this case) Google and others.  I was the
one who used the word "fad" to refer to such recently
promoted "hard-reject" rules and pointed out that many
smaller organizations will be unable to cause legitimate
mail/postings to comply with such rules anytime soon,
simply because it takes time to roll out new protocols to
all the worlds legitimate e-mail sending servers.

As for the suggestion to forbid links to servers other than
OpenSSL.org servers, this will be fatally flawed as it will
block discussions of such common OpenSSL related topics as:

- URLs of published security research (such as the home
 pages of new vulnerability descriptions).

- URLs of sites that publish OpenSSL related software, such
 as OpenSSH, 

Re: [openssl-users] Fwd: CONGRATULATION____REF#87670

[Jakob Bohm]

On 04/04/2016 22:28, Johann v. Preußen wrote:
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.



No one (until about 2 hours ago) were discussing how the
particular "From" address got past the "you must be
subscribed to post" filter, maybe the spoofed From address
happened to be a subscriber, maybe there is a bug in the
list management software or configuration.

There was discussion of which generic "hard-reject" filters
should be applied and someone suggested prematurely
applying a number of recently "trendy" such rules promoted
by (ironically in this case) Google and others.  I was the
one who used the word "fad" to refer to such recently
promoted "hard-reject" rules and pointed out that many
smaller organizations will be unable to cause legitimate
mail/postings to comply with such rules anytime soon,
simply because it takes time to roll out new protocols to
all the worlds legitimate e-mail sending servers.

As for the suggestion to forbid links to servers other than
OpenSSL.org servers, this will be fatally flawed as it will
block discussions of such common OpenSSL related topics as:

- URLs of published security research (such as the home
 pages of new vulnerability descriptions).

- URLs of sites that publish OpenSSL related software, such
 as OpenSSH, stunnel, the Shining Light Windows binaries of
 OpenSSL etc.

- URLs that are showing interoperability problems with
 OpenSSL.

- URLs of independently published OpenSSL patches (that
 have not yet been accepted into the OpenSSL repositories).

- URLs necessitated by the byzantine legal rules regarding
 which web servers are allowed to publish cryptographic
 software written by which people for use by which other
 people.

These categories of non-openssl.org URLs occur frequently
in legitimate posts to this list and cannot be replaced by
some private openssl.org hosted equivalent of pastebin.com
etc.


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.

You are now going way outside anything discussed previously,
please enlighten the list as to what you are possibly
talking about here.

So far the only known breach is an apparent breach of
*Google owned* e-mail servers, allowing perfect spoofing
of gmail.com addresses by causing the fake mail to be
sent by *exactly* the same servers with *exactly* the
same headers as legitimate mails by the legitimate user of
the spoofed e-mail address.

This does not expose any of the names of any e-mail
addresses stored by the OpenSSL organization, unless
that data can be extracted by e-mailing a command to
listserv from a spoofed administrator e-mail address and
any of those administrator e-mail addresses are actually
hosted by Google.



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.



Posts by others indicate that the *spoofing* activity
seemed to have stopped for multiple gmail addresses,
including the e-mail address of one person posting such
an observation, indicating a likelihood that Google fixed
the underlying security issue.



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 

Re: [openssl-users] Fwd: CONGRATULATION____REF#87670

[Johann v . Preußen]

if this list was for tex-mex cooking recipes or ES vacation rentals, i would 
agree that expectations for privacy might be very low and individual subscribers 
are responsible to be as circumspect as they personally feel they must be.


however, this is a list of people in the fore-front of addressing global 
security issues and -- i would think -- subscribers would certainly want their 
personal info (U.S. Title XIII PII) to be as secure as the issues they are 
grappling with rather than having it published in the clear. the security issue 
re the subscriber email addr spreads beyond the actual person as well. suppose 
we have henrietta schmidt who is the email security officer for xyz corp who is 
addressed as h.schm...@xyz.com. since most large firms and almost all gov 
agencies have rigid mailbox addressing schemes, it is quite possible to 
extrapolate from this one email addr to a much wider range. like xyz's CIO joe 
blow who is most likely to be found at j.b...@xyz.com or some close variant.


the payoffs for the successful breaching of systems of large firms and 
governments is huge and it does not require much imagination to deduce that the 
pantheon of perpetrators is large, their diligence is intense, and their numbers 
are not confined to a bunch of "script kiddies". quite plainly, i do not believe 
that openssl should be making their job easier.


--
Thank you,

Johann v. Preußen

On 2016.Apr.04 14:49, Jeffrey Walton wrote:

On Mon, Apr 4, 2016 at 5:32 PM, Johann v. Preußen  wrote:

right now our conversation is bi-directional since the listserv is off-line.

i also looked at the headers and they do seem to originate within google
itself ( bogon receipts). so, are you telling me that the mere fact that an
email is addressed to the list will get it published without verifying that
the sender is a subscriber?

everything else i mention relate to the needless exposure of the
subscriber's real name and email addr and the permitting of private anchors.
obviously, i believe that these practices greatly increase security risks
for the subscriber and will subject them to a potential flood of noxious
junk.

Yes, I agree Johann. The thing I would point out is there's usually no
expectation of privacy with a mailing list, so users should not be
surprised if their email address shows up in a traditional email
header or an X-header somewhere.

What piqued my interest was that sudden spurt of spam. Something was
not right, but I could not finger it.

Jeff





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Fwd: CONGRATULATION____REF#87670

[Johann v . Preußen]

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




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Fwd: CONGRATULATION____REF#87670

[Johann v . Preußen]

right now our conversation is bi-directional since the listserv is off-line.

i also looked at the headers and they do seem to originate within google itself 
( bogon receipts). so, are you telling me that the mere fact that an email is 
addressed to the list will get it published without verifying that the sender is 
a subscriber?


everything else i mention relate to the needless exposure of the subscriber's 
real name and email addr and the permitting of private anchors. obviously, i 
believe that these practices greatly increase security risks for the subscriber 
and will subject them to a potential flood of noxious junk.


--
Thank you,

Johann v. Preußen

On 2016.Apr.04 13:46, Jeffrey Walton wrote:

On Mon, Apr 4, 2016 at 4:28 PM, Johann v. Preußen  wrote:

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.

Yeah, this particular message looks like classic spam (headers
available at 
http://groups.google.com/forum/#!original/mailing.openssl.users/eXD0UYueasw/jsZtjTLPCQAJ).

When the spam was getting through, I checked some of the headers and
most were coming from Gmail users. See, for example,
http://pastebin.com/hRAtRt7S. That particular message likely had its
spam score lowered because of the DKIM signing.

I was also contacted offlist for the spam I was sending. I saw the
headers on two of the messages, and they clearly were from me and
submitted through Google's web interface. They looked just like the
headers in http://pastebin.com/hRAtRt7S. I did not send them, and they
did not show up in my Outbox.

Its the reason I'm guessing Google services had a vulnerability that
was silently patched.

Jeff





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Fwd: CONGRATULATION____REF#87670

[Jeffrey Walton]

On Mon, Apr 4, 2016 at 4:28 PM, Johann v. Preußen  wrote:
> 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.

Yeah, this particular message looks like classic spam (headers
available at 
http://groups.google.com/forum/#!original/mailing.openssl.users/eXD0UYueasw/jsZtjTLPCQAJ).

When the spam was getting through, I checked some of the headers and
most were coming from Gmail users. See, for example,
http://pastebin.com/hRAtRt7S. That particular message likely had its
spam score lowered because of the DKIM signing.

I was also contacted offlist for the spam I was sending. I saw the
headers on two of the messages, and they clearly were from me and
submitted through Google's web interface. They looked just like the
headers in http://pastebin.com/hRAtRt7S. I did not send them, and they
did not show up in my Outbox.

Its the reason I'm guessing Google services had a vulnerability that
was silently patched.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Fwd: CONGRATULATION____REF#87670

[Jeffrey Walton]

> 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
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Fwd: CONGRATULATION____REF#87670

[Jakob Bohm]

Key Fact: Not all e-mail is sent by or through 800 pound
gorilla providers such as Google.

Many organizations and businesses (including the OpenSSL
project) run their own e-mail servers and simply don't
have the manpower to track and implement every new
"anti-spam flagging" fad that comes along.

For example SMTP2SMTP encryption (aka SMTP with STARTTLS
and various configuration option choices) is default in
some MTA implementations, yet nearly impossible to add
in others.

Therefore setting up rules banning any domains not
implementing the latest "standard" anti-spam measures
would be extremely stifling and would force many more
people to send through surveillance-happy organizations
such as Google.

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.


On 03/04/2016 00:30, Ben Humpert wrote:

Fun Fact: (For me) Gmail often marks completely legit emails from
mailing lists as spam and you manually have to mark them as "no spam".
The fun comes in when you notice that actual spam is not marked as
such at all.

Looks like strong encryption is much easier to develop than a decent
spam filter.

The main problem I guess is that neither Google nor any other major
email provider actually block other email providers who do not offer
SPF, SMTP2SMTP encryption or whatever else. If they would do so, we
would have solved most major (email) problems within a week or at
least a month. Either by forcing those to offer these security
features or by "killing" these providers indirectly.

2016-04-02 17:41 GMT+02:00 Jeffrey Walton :

On Sat, Apr 2, 2016 at 11:24 AM, Salz, Rich  wrote:

why is junk like this not being caught?

Almost all of it is.  Nothing is perfect.  Thanks for your understanding and 
patience.

I was looking at some of it landing in my Inbox. Its all from Gmail
users. The headers are Gmail headers submitted via the web. The DKIM
signatures are OK. There are no headers to indicate its been
forwarded. The {from|return|reply to} address does not appear to
forged. Here's an example header from another Gmail user who contacted
me: http://pastebin.com/hRAtRt7S.

I've also had a couple of people contact me asking me to stop spamming
them. I looked at two of those headers, and it clearly appears to be
coming from me though I did not send it (and no evidence in my
Outbox).

I'm thinking there's a vulnerability in the Gmail or Google servers we
have not heard about.

Jeff
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



--
Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10 


This message is only for its intended recipient, delete if misaddressed.
WiseMo - Remote Service Management for PCs, Phones and Embedded


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Fwd: CONGRATULATION____REF#87670

[Johann v . Preußen]

i guess the reason for my original post was that i was so taken aback by the 
fact that the body had so many red flags:
1.) '$1000': this list certainly is about money, but it would seem unlikely that 
actual terms not coupled with something like [loss|cost] or the like would seem 
improbable;

2.) 'giftcard': seems like a very unlikely discussion element here;
3.) 'shipment': ditto;
4.) 'informations' (sic): i realize this list -- being international in scope -- 
will not exhibit perfect English usage at all times (even from native English 
speakers). however, poor English (even just spell-checked) combined with other 
filters could push the score high enough;
5.) links: examples are always very constructive, but it is certainly not much 
of an inconvenience to limit active anchors to major sandboxes or even one 
operated by openssl; and
6.) obfuscation: the worst and most-telling is the fact the content clearly was 
designed to bypass filters by couching the desired message within a highly 
unusual number of non-prose, non-technical symbols. in this blatant case  there 
was a complete lack of prose and that will just never occur in this list.


this list is active, but a very low-volume one and more intensive body checks 
that route questionable entries to some monitoring box would seem to be well 
worth the small resource utilization required.


moreover, i do not notice anyone from google's security team(s) chiming in here 
and it would seem that good old 'otisevans98' will skate without consequence for 
the foray against this list which is entirely about security. perhaps added body 
filtering and actual human intervention would serve the desired benefit of 
having such intrusions actually result in an abuse complaint to the MTA 
operator.


--
Thank you,

Johann v. Preußen

On 2016.Apr.02 15:30, Ben Humpert wrote:

Fun Fact: (For me) Gmail often marks completely legit emails from
mailing lists as spam and you manually have to mark them as "no spam".
The fun comes in when you notice that actual spam is not marked as
such at all.

Looks like strong encryption is much easier to develop than a decent
spam filter.

The main problem I guess is that neither Google nor any other major
email provider actually block other email providers who do not offer
SPF, SMTP2SMTP encryption or whatever else. If they would do so, we
would have solved most major (email) problems within a week or at
least a month. Either by forcing those to offer these security
features or by "killing" these providers indirectly.

2016-04-02 17:41 GMT+02:00 Jeffrey Walton :

On Sat, Apr 2, 2016 at 11:24 AM, Salz, Rich  wrote:

why is junk like this not being caught?

Almost all of it is.  Nothing is perfect.  Thanks for your understanding and 
patience.

I was looking at some of it landing in my Inbox. Its all from Gmail
users. The headers are Gmail headers submitted via the web. The DKIM
signatures are OK. There are no headers to indicate its been
forwarded. The {from|return|reply to} address does not appear to
forged. Here's an example header from another Gmail user who contacted
me: http://pastebin.com/hRAtRt7S.

I've also had a couple of people contact me asking me to stop spamming
them. I looked at two of those headers, and it clearly appears to be
coming from me though I did not send it (and no evidence in my
Outbox).

I'm thinking there's a vulnerability in the Gmail or Google servers we
have not heard about.

Jeff
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users




smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Fwd: CONGRATULATION____REF#87670

[Ben Humpert]

Fun Fact: (For me) Gmail often marks completely legit emails from
mailing lists as spam and you manually have to mark them as "no spam".
The fun comes in when you notice that actual spam is not marked as
such at all.

Looks like strong encryption is much easier to develop than a decent
spam filter.

The main problem I guess is that neither Google nor any other major
email provider actually block other email providers who do not offer
SPF, SMTP2SMTP encryption or whatever else. If they would do so, we
would have solved most major (email) problems within a week or at
least a month. Either by forcing those to offer these security
features or by "killing" these providers indirectly.

2016-04-02 17:41 GMT+02:00 Jeffrey Walton :
> On Sat, Apr 2, 2016 at 11:24 AM, Salz, Rich  wrote:
>>
>>> why is junk like this not being caught?
>>
>> Almost all of it is.  Nothing is perfect.  Thanks for your understanding and 
>> patience.
>
> I was looking at some of it landing in my Inbox. Its all from Gmail
> users. The headers are Gmail headers submitted via the web. The DKIM
> signatures are OK. There are no headers to indicate its been
> forwarded. The {from|return|reply to} address does not appear to
> forged. Here's an example header from another Gmail user who contacted
> me: http://pastebin.com/hRAtRt7S.
>
> I've also had a couple of people contact me asking me to stop spamming
> them. I looked at two of those headers, and it clearly appears to be
> coming from me though I did not send it (and no evidence in my
> Outbox).
>
> I'm thinking there's a vulnerability in the Gmail or Google servers we
> have not heard about.
>
> Jeff
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Fwd: CONGRATULATION____REF#87670

[Jeffrey Walton]

On Sat, Apr 2, 2016 at 11:24 AM, Salz, Rich  wrote:
>
>> why is junk like this not being caught?
>
> Almost all of it is.  Nothing is perfect.  Thanks for your understanding and 
> patience.

I was looking at some of it landing in my Inbox. Its all from Gmail
users. The headers are Gmail headers submitted via the web. The DKIM
signatures are OK. There are no headers to indicate its been
forwarded. The {from|return|reply to} address does not appear to
forged. Here's an example header from another Gmail user who contacted
me: http://pastebin.com/hRAtRt7S.

I've also had a couple of people contact me asking me to stop spamming
them. I looked at two of those headers, and it clearly appears to be
coming from me though I did not send it (and no evidence in my
Outbox).

I'm thinking there's a vulnerability in the Gmail or Google servers we
have not heard about.

Jeff
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Fwd: CONGRATULATION____REF#87670

[Salz, Rich]

> why is junk like this not being caught?

Almost all of it is.  Nothing is perfect.  Thanks for your understanding and 
patience. 
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Fwd: CONGRATULATION____REF#87670

[Johann v . Preußen]

why is junk like this not being caught?

--
Thank you,

Johann v. Preußen

On 2016.Apr.01 12:27, Otis Evans wrote:


923 Dunlap st

On Apr 1, 2016 1:02 PM, > 
wrote:



/
Attn:__here__is__your___$l∅∅∅__Facebσσk__giftcard.

__Wε__Nεεd__Yσμr__Shiρmeηt__Infσrmatiσηs__

Click_Here 


































/







smime.p7s
Description: S/MIME Cryptographic Signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Fwd: CONGRATULATION____REF#87670

[Otis Evans]

923 Dunlap st
On Apr 1, 2016 2:27 PM, "Otis Evans"  wrote:

> 923 Dunlap st
> On Apr 1, 2016 1:02 PM,  wrote:
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> * Attn:__here__is__your___$l∅∅∅__Facebσσk__giftcard.
>> __Wε__Nεεd__Yσμr__Shiρmeηt__Infσrmatiσηs__ Click_Here
>>  *
>>
>>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Fwd: CONGRATULATION____REF#87670

[Otis Evans]

923 Dunlap st
On Apr 1, 2016 1:02 PM,  wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> * Attn:__here__is__your___$l∅∅∅__Facebσσk__giftcard.
> __Wε__Nεεd__Yσμr__Shiρmeηt__Infσrmatiσηs__ Click_Here
>  *
>
>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users