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
