ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] [Shutup] Proposed Charter for something

2015-12-10 11:50:59
On 12/10/2015 12:11 PM, Martijn Grooten wrote:
On Thu, Dec 10, 2015 at 11:16:40AM -0500, Chris Lewis wrote:
There really are no technical differences whatsoever between a
blackhat and a whitehat trying to protect their identity. The ONLY
saving grace is that (in the spam space) the blackhat is forced to
resort to methods that scale high enough for an adequate ROI, while
the whitehat usually doesn't care that much.

Most spam filtering - again used in the broad sense - only cares about
the identity of the sending organisation (ISP, company, etc.). And
sometimes not even that. If an email body matches some (fuzzy)
signature, it gets blocked, often regardless of who sent it from where.

I would contend that very little spam filtering cares what the identity is at all. The identifier tokens just being more grist for the filtering engine that may help or may not.

For example, Bayes doesn't care what the words it scans mean, it looks for statistical similarity with stuff it knows is bad and stuff it knows is good.

It's only when said organisation doesn't do a good enough job of
checking the identity (or the hat colour) of the sender, that being able
to find the actual sender matters to everyone else.

Or, sometimes, when you're trying to figure out where it's going to pop up next and/or warn providers of the toxic customer.

Tor, for example, being a case in point.  Tor would be ideal for
spam. And it was for a bit.  Slow, but worked.  I don't know whether
the fact that the tor network became so slow as to be unuseable, or
that the screams from the "spammed" turned the day, but so few tor
exit nodes support outbound port 25 nowadays that it isn't a big
problem.

If they hadn't all blocked that port (it's the default, I believe)

Newbie ;-) It wasn't always that way. How do you think that came to be that way?

then every DNSBL would add the exit nodes;

Precisely.

Tor, by design, doesn't hide the
nodes' IP addresses and it's easy to check if a certain IP address is
or was a Tor exit node at a given time.

The aforementioned boilerplate describes that in copious detail so as to make it easier for the DNSBL operator to use their exit node list to whitelist them unconditionally no matter what comes out of them.

Er, no.  We're very polite.  We have boilerplate for that too.

They also get told that at least we don't treat tor nodes any differently than any other, and a reminder to not co-locate a tor node with their own servers/network and thus share the reputation of the exit node.

If being able to hide (the geolocation of) your submission IP address is
of vital importance, then this is the way to use email. For most people,
this isn't necessary, but it is my belief that at the very least we
should help organisations that wish to protect personal data for all of
its users to do so in a way that doesn't seriously harm the existing
email infrastructure.

The tor "group" had to make a similar decision, when it came to the serious harm to the viability of their own infrastructure by what, at the time, was unfettered spam.

I2P is going through a similar revolution now - going from a theology of the "bits must be free and more importantly private" to a realization that their future relevance relies on not becoming an infamous source of harm. They have to come up with innovative ways to preserve what they want it to be, in the face of those wishing to pervert it to being a safe haven conduit for their abuse.

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

<Prev in Thread] Current Thread [Next in Thread>