On 12/02/2015 02:17 PM, Ted Lemon wrote:
Wednesday, Dec 2, 2015 1:22 PM Richard Clayton wrote:
Does the linked article say anything to support the point you made above?
It's a study about the emotional impact of fraud, which I can tell you from
personal experience, without reading the study, is pretty overwhelming, for
many of the reasons cited in the study.
The linked article does support why it's so important to prevent things
like this happening, and why people like Richard (and myself and many
others here) use items of information like we're talking about here to
do just that. Prevent it where we can, stop it getting through when we
can, and help LE catch the guys doing it. This is (part of) what many
of us do for a living.
This is why I don't want 419 scammers to be able to scrape identifying info
about my elderly relatives off of their email.
Do you have any evidence that 419 scammers have any email from your
elderly relatives that's amenable to scrape such info off of, let alone,
have any use for such identifying information? All they need is an
email address and a trickable recipient. Your elderly relatives have
probably already put their street address, phone numbers, and photos of
their pets (complete with geolocation in the JPGs) into the emails.
The perceived threat presented by archived mailing lists isn't so much
about received lines (archives often don't contain much header detail
anyway), but the addresses themselves. That is what is of interest to
419 scammers (and the spammer that spammed me less than 3 hours after
creating this address for the sole purpose of this discussion!).
Shouldn't this RFC be about obfuscating email addresses in mailing list
archives? It'd have more effect on 419 scammers.
As for the cops to whom you refer, who aren't mentioned in the article you
mentioned, they would probably benefit from reading the RFC we've been talking
about writing, since I suspect some of the information they need would be
captured in it.
Here's the draft in question:
[This is brief draft critique, which you can ignore, except for the fact
that it indicates why a WG is necessary]
The only operative content is:
The purpose of this document is to propose a mechanism that
implementers and operators of SMTP agents may adopt to mitigate the
Note the "may adopt" - sounds optional right?
The "from clause" of the Received header MUST NOT be added by SMTP
entities concerned with the privacy of their clients.
1) Is there anybody out there dumb enough to assert that they're NOT
concerned with the privacy of their customers? This is therefore
tantamount to an absolute requirement, not an option, and could be
treated as such and potentially enforced through the courts, as well as
by providers using this as an easy-out to do nothing whatsoever when
abuse is reported to them.
2) I don't see anything in there that would mitigate the loss of this
information in either the descriptive text nor the example given - since
the from clause is simply omitted rather than, for example, translated
into a interpretable-only-by-the-provider identifier blob.
3) It entirely begs the question of when the information of potential
privacy concern isn't in a "from" clause. Such as providers who issue
X-Originating-IP headers, "authenticated as x on y" clauses in Received
or other headers, and perhaps even details of personal crypto key
identifiers. Protocol specifications are intended to be taken
literally, a protocol specification that doesn't effectively do what you
want is useless.
4) The security section has nothing about the downsides of removing this
information or even hint at less-privacy invasive alternatives.
How much of this is really a social issue that has to be addressed with
societal action compared to a technical bandaid that only helps in rare
circumstances? If you're concerned about, say, governmental
surveillance, I'm thinking that fixing your government is better than
(only occasionally) hiding just this teensy bit of information from them.
ietf-smtp mailing list