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>
