[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.<mailto:otisevans98 at gmail.com>

--
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 <noloader at gmail.com>:
>> On Sat, Apr 2, 2016 at 11:24 AM, Salz, Rich <rsalz at akamai.com> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160402/8b3ad7f5/attachment-0001.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/20160402/8b3ad7f5/attachment-0001.bin>