ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: Blocking improperly signed messages

2006-12-15 12:00:57
Wietse Venema wrote:
Frank Ellermann:
Steve Atkins wrote:
to summarize, you believe that SSP is drastically less likely
to provide any operational benefit or achieve widespread
deployment than SPF?
I wouldn't compare SPF and SSP, they're mostly unrelated.  For
a comparison of SenderID and SSP it's hard to judge, the "PRA"
concept makes more sense than looking only at the 2822-From.

Isn't (SSP for DKIM) analogous to (SPF for IP addresses)?

Isn't (SSP versus MLMs) analogous to (SPF versus forwarding)?

The arguments seem to have a lot in common to me.

I can see your point, but its not really the same. Any arguments are ones of politics and management, not technical.

SPF issues had to do with a technical barrier where at transition points (e.g., routers), the client IP has changed with the RFC required persistent return path. Solutions for this are:

   - RFC 4405 SUBMITTER
     http://www.ietf.org/rfc/rfc4405.txt

   - Non-standard, altered reversed path methods


DKIM/SSP does not have a technical problem with transitions points hence one of its major attraction.

SPF mail senders are sending to a MDA with no presumption or expectation that any further routing will be done. As far as the sender is concern the job is done. The SPF receiver, if its going to further route, is required to maintain the LMAP (Domain::IP) relationship.

Since this not a technical issue with DKIM/SSP, the question debated here with SSP had to do with controlling the DKIM-BASE signature process. That is more of "feature", "management" issue. Not a technical barrier.

On a related note, SSP is really not the big concern with MLM or mailing list servers, but rather DKIM-BASE mail integrity issues are nearly 100% guarantee, making anything beyond DKIM-BASE a moot issue.

However, at the very least, SSP can help control the "bad side" of such operations where it is NOT expected to happen.

---
Hector Santos, CTO
http://www.santronics.com




_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html