ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Should DKIM drop SSP?

2005-10-26 21:04:19
In <593A1176-AF0D-452D-8157-DCAD54756CBC(_at_)mail-abuse(_dot_)org> Douglas 
Otis <dotis(_at_)mail-abuse(_dot_)org> writes:

One could view DKIM as a mechanism that establishes an accountable  
domain for the messages contained within the email message transport  
system.  By limiting the scope of DKIM to being a mechanism that  
provides an accountable domain for the transport system, a great deal  
of benefit can be derived without threatening the integrity of the  
transport system.  [...]


I don't think that DKIM should drop SSP.

That said, let me play devil's advocate for a bit.


Experience with SPF has shown that there *will* be people who will
reject email because they didn't receive an SPF PASS result, even if
that result is NEUTRAL.  These same people will not reject email
just because there weren't SPF records found, even though that is
supposed to be the same meaning as an SPF NEUTRAL result.

Because of this, there *are* be people who will either not publish SPF
record, or will withdraw publication of SPF records because any
failure to authenticate a message, for any reason, could cause a
legitimate message to be rejected.

One of the reasons why Tripp Cox gave for removing SPF records for
Earthlink was "SPF and SenderID posed serious risks to the
deliverability of legitimate email. We believe it is better to publish
no record at all than to publish a record that may be subject to
misinterpretation."[1] Before Tripp removed Earthlink's SPF records,
their records ended with "?all", which should have given NEUTRAL
results for any email that didn't get an SPF PASS.  According to the
specs, there is no way that Earthlink's SPF record should have hurt
any more than not publishing any SPF record at all.


So, you can rest assured that the mere publication of SSP information
will cause some people to reject email from the domain that hasn't
been signed, has been signed but fails to validate, or has a third
party signature even if it is approved.  You can also expect some
people to reject that has valid DKIM signatures, but no SSP
information. 

Some people, maybe even major players, will refuse to publish DKIM
records because it may cause legitimate email to be rejected, even if
they publish the loosest of requirements.


I think there could be a reasonable level of demand for a solution
that could only give positive results.  One that makes it so that you
really can't easily tell if a message that doesn't validate is because
the validation failed, or because it is like 99% of the email today
that never could have been validated.


I'm not sure that simply removing SSP from DKIM would be enough, since
there will still be some people who reject email based on signature
failures alone.  However, including SSP will certainly give people who
what to take a very hard line to reject more legitimate email because
it doesn't pass with flying colors.

I suspect that people who are too scared about legitimate email being
rejected to publish SPF or DKI/SSP records, but want some form of
authentication, will need to stick with something like DNS whitelists
or HELO checking.


</devil's advocate>


-wayne

[1] http://www.trippcox.com/blog/archives/2005/08/much_ado_about.html
_______________________________________________
ietf-dkim mailing list
http://dkim.org