Hector Santos wrote:
there was a TECHNICAL DESIGN issue with SPF when it came to
indirect mail transactions where there is more than one hop.
The decision that RFC 1123 5.3.6(a) and anything built on it
is "broken by design" was intentional, obvious, and covered
by RFC 821. If folks seriously try to compare an enumeration
of "permitted" sender IPs while talking with one of their own
MTAs on the side of the receiver it unsurprisingly won't work.
The number of hops has nothing to do with it, there can be as
many hops as you like before the border or behind it, check
SPF at the border and you're fine. As long as you reject FAIL
at the border you are also fine in scenarios where unmodified
MAIL FROMs are forwarded by a third party to you.
Pretty basic, no "Bob can't resend mail from Alice" involved.
As soon as Bob got Alice's mail it is his mail, no amount of
weasel words could change this.
DKIM-BASE does solve the forwarding problem
DKIM doesn't "solve" a "forwarding problem", for starters it
doesn't have any "forwarding problem", no need to "solve" it.
If SSP attempts to infringe on or otherwise constrain forwarder
or receiver practice, then it may very well become as relevant
as SPF.
Again, I agree over all, but I really don't care and I don't
think it will be productive to compare it to SPF or question
its relevance.
Comparing http://www.openspf.org/Statistics with a not yet ready
draft would be pointless, and SSP is targeted for a far narrower
audience, victims of phishing. Comparing it with PRA could make
sense at some point in time, the SSP folks will say when, they
start later, earlier comparisons would be unfair.
If there is one legitimate comparison, then we should look at
the relevance of DomainKeys (DKEYS).
Comparing the deployment a not yet ready draft with a historic
RFC, what's that good for ? Sounds like comparing SPF with
the true RFC 821 believers still trying to use reverse routes
for their "forwarding problem".
DKIM risk falling into the same waste land if we don't resolve
the SSP issue.
I don't get it, how can DKIM fall into waste land when GMail,
Ironport, and others use it ? Unfortunately GMail doesn't
publish SPF FAIL, but they offer at least a PASS, apparently
they also reject FAIL. No waste land in sight, or did you
mean PRA ?
Domainkeys also didn't fall into waste land, it was published
as historic after DKIM was ready, intentionally.
I am not looking to lock in DKIM implementation with some
very limited "batteries required" Trust Service concept.
If you use DKIM as receiver without some kind of white list
I've no idea what you are actually doing, but IMO you don't
need a Trust Service to create a white list, roll your own.
You could even check some kind of "best guess SSP" before
SSP is ready, like "best guess SPF" that's nothing that will
end up in a RFC, it's deep in "receiver policy" territory.
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html