ietf-smtp
[Top] [All Lists]

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

2015-11-30 16:51:41
Monday, Nov 30, 2015 7:04 AM Richard Clayton wrote:
In message <1448858775386-ceecd236-8b11ac04-a03b4438(_at_)fugue(_dot_)com>, 
Ted
Lemon <mellon(_at_)fugue(_dot_)com> writes
... and one of the things that the ML will be processing will be the
(tokenised contents of the) header fields... so having a pattern (of any
kind) within the header fields has the potential to be extremely helpful
in distinguishing good from bad

Very true.   And it's likely that there is some percentage, P, of messages that 
are prevented from being delivered because that information is in the Received: 
header field.   If P is 99, obviously we'd better not take that information out 
of the Received: header field.   If it's .0001, then this isn't a good argument 
for retaining the information.

It rather escapes me how one of your users will be able to determine
whether you received the email from a domain which had SPF at the time
at which you received it unless you record that information along with
the email (or do you think that DNS results are constant for all time?)

Anything that involves a volitional act on the part of some person is an 
exception.   The interesting question is, does SPF provide me any greater 
effectiveness in my system's automatic behaviors.   The answer is yes.

If you're relaying the email on to somewhere else then you're assuming
that there's a mechanism by which your policy regarding SPF becomes
known to those other people.

Why would I be relaying mail on?   Only for a mailing list.   For the mailing 
list, what I want SPF to validate is that the mail came from the mailing list.  
 I'm relying on the mailing list provider to filter spam in this case; any 
secondary spam filtering that I do on the tail end is going to be compromised 
by the loss of information when the mail goes through the list relay.   Still 
might be worth it, but what is the value of P in this case, for a general 
solution, as opposed to a one-off heuristic?

  If there is no SPF for the domain 
that sent the message, I would like to just discard it as spam, but that's 
not 
safe to do because so many small sites don't implement SPF or get it wrong.   
But in any case where there is no SPF record, the site is definitely not 
trustworthy:

that's a shame, I consider myself very trustworthy and I've never
bothered with SPF :-(

Right, and because you don't use SPF, I can't whitelist you, because anybody 
can send me mail claiming to be from you, and I have no prima facie basis for 
rejecting it (unless you use DKIM, I suppose).  The problem isn't that _you_ 
aren't trustworthy: it's that your system for delivering mail to me isn't.  I 
could maybe study your headers over time and come up with some heuristic or 
machine-learning system that would distinguish between you and an imposter, but 
you're making me do a hell of a lot of work when setting up SPF is really quite 
easy.


--
Sent from Whiteout Mail - https://whiteout.io

My PGP key: https://keys.whiteout.io/mellon(_at_)fugue(_dot_)com

Attachment: pgpxbqnh0NDHW.pgp
Description: PGP signature

_______________________________________________
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>