Hector Santos wrote:
So this is mostly about dealing with the anonymous sender.
How do we change the anonymity of the sender?
Well, first we need to decide "who is the sender?" This
seems to be a source of contention in this group.
Regardless of who or what is the sender, the commonality
is the fundamental concept of finding the "anchor" for
the discovery process.
We, as a group, decided the established universal entity
for the authorship of the message is the x822.From address
domain and that would be the "anchor.". I believe a main
reason is that required by x822 to be present, especially
when there no other markers, such as a DKIM signature, in
the message.
"Author" and "sender" are intentionally different concepts
in e-mail, and the "we" in TINW didn't manage to reconcile
them where it matters, in 2822upd.
JFTR, Dave and others proposed to deprecate Resent-* header
fields in 2822upd (on the 822 list), a significant part of
the problems with SSP. RFC 5016 4.3 even hints broadly at
the problem, "Bob" (a mailing list or resender) has to be
free to resend Alice's SSP mail, because 2822upd says that
he's free to do this.
A receiver rejecting Bob's resent mail because Alice wants
this in her SSP might be at odds with (2)822(upd). If you
want to get rid of Resent-* update or obsolete RFC (2)822,
"on the DKIM list" won't fly. At the moment you can only
hope that Bob doesn't invalidate Alice's DKIM signature.
With mailing lists violating 2821(bis) 3.10(9) as they see
fit - up to "replace existing Sender" - SSP is in trouble,
and "don't use it on mailing lists" is shaky without a way
to identify a mailing list address. We're not sure what
Bob is up to, and worse, Alice can't be sure.
SPF at least went to the trouble of justifying its mode of
operation as "allowing to emulate 821 as good as possible
after 1123", for SSP it's apparently "even 822 was already
wrong". PRA at least tried to (ab)use (2)822 header fields
in a plausible way, SSP does not even pretend to understand
what they mean and how they are used.
We can not guarantee the Sender: address will be there and
if we wanted to use this, then I believe we are forced back
to a x821 design because if missing, the only reasonable
substitute is the Return-Path:.
Well, a solution compatible with what most mail standards say
certainly exists already, modulo Doug not liking certain uses
of MX, because it could be an attack vector.
*All attempts to outsmart PRA are doomed*. I think that's
a kind of "IETF law" in the style of "Usenet laws". Adding
a lemma based on "PRA isn't good enough" should be simple.
I found for ~80-84% of the time, the following domain
association holds true in non-list server environments:
x821.MailFrom == x822.From [== x822.Sender if present]
Great, with 16-20% false positives and 90% spam it should be
clear that rejecting all mails from odd IPs on Fridays is a
"better" mechanism (it's certainly cheaper than PRA or SSP).
the From: address is the most reasonable and most practical
anchor available to today for an unsolicited, anonymous,
including unsigned transaction to perform a SSP lookup.
I give up again, this is hopeless. Get an experimental RFC
for SSP and check out what it does for the desperate folks
wishing to participate. Beware of volunteers too timid to
publish a clean SPF PASS / FAIL policy like Ebay / Paypal,
they might be in for a surprise (from their POV).
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html