[Top] [All Lists]

Re: [ietf-smtp] [Shutup] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG (fwd)

2015-12-01 12:22:10
Hash: SHA1

On 12/01/2015 11:51 AM, Ted Lemon wrote:

| We are seeing providers right now disappearing IP address
| information for the submission IP source address, so your logic
| here would suggest that there is in fact a downside to including
| that information; otherwise it would not have disappeared.

What we have now is a very small number of providers doing this on
purpose (I can count the number of major providers doing it with the
fingers of one hand), and a still very small, but marginally larger
set of providers not providing it because their infrastructure doesn't
know what it is and/or their software just doesn't do it for one
reason or another.

On the other hand, we can see that that the lack of that information
presents difficulties to filtering technologies.  When you get a
series of harassing emails from a given site originating from a given
user that's forging from lines and mutating content, you have nothing
concrete to filter on to distinguish it from other email from the same

Leaving you with an all or nothing situation of blocking the whole
provider.  Which isn't a big drawback if the provider is good at
stopping abuse because the problem won't last long, but, the largest
provider in question often isn't, especially in the case of individual
harrassment.  Indeed, without that information being present (or not
being accessible without great effort using the provider's server
logs), it can cause significant difficulty for the provider doing
anything about it even if they wanted to.  IOW: if even the provider
doesn't know where it's coming from (or if finding out is too
expensive to do at scale), then everybody (including the poor user
with the infected box) is SOL.

One of your other points is that the received lines aren't
standardized.  Well, yes, that's true.  But that is in fact an
advantage to filters.  The simple fact of different
formats/idiosyncratic behaviour gives filtering technologies more
leverage to make filtering decisions that have nothing whatsoever to
do with IP addresses.  We use this sort of information to great
benefit - as do the largest email providers.

"Standardized" or not, Received lines provide a rich detail of fodder
for filtering, whether or not the filter manages to understand what
the received line is trying to say about where the email allegedly
came from or how it got there.  The IP could just as easily be a
non-reversible encrypted blob unique to the sending user that only the
provider understands, but the receiver can filter on.

I say "allegedly", because the actual source (personal attribution) of
the email is generally irrelevant to filtering. Our primary goal is
stopping the trash, a secondary goal is helping the infectee fix their
problem, but if the provider wants to interfere with the latter, well,
we can live with it.
Version: GnuPG v2.0.22 (GNU/Linux)


ietf-smtp mailing list

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