Douglas Otis wrote:
Rejections based upon the MailFrom IP address path failures,
regardless of the asserted SSP policy, would diminish DKIM's
delivery integrity.
SPF FAIL users have had it with "delivery integrity", DKIM or
otherwise, they are determined to eradicate the backscatter at
all costs. The proposal to use DKIM PASS as second opinion is
from a receiver's POV worried about "traditional forwarding".
After the final dot of the DATA at the border is the last point
in time to arrive at a reliable decision wrt reject vs. accept.
TPA-SSP can better validate MailFrom
| The application of TPA-SSP at the MailFrom represents an
| entirely optional strategy which may or may not prove either
| effective or practical. The MailFrom scope is offered only
| for experimentation.
Please inform me about the outcome of the optional experiments,
RFC number, implementations, test suite, deployment, the works.
What you have at the moment is only a draft, it would be unwise
to confuse this with worldwide adoption.
A new resource record is not a solution, as both record types
must still be published to ensure legacy compatibility.
Existing SPF versions (in essence v=spf1 and spf2.0/pra) must do
this, future users of the now existing SPF RR are not forced to
replicate their policies in TXT records. Or are you talking
about the problem with existing MS platforms and new RR types ?
I hope that this will go away.
Phillip's concept holds greater promise
We failed to get this WG to support it :-(
and does not result in records that must contain "everything",
including the kitchen sink.
Records can be separate while sharing an RR type. Of course the
complete set including the kitchen sink has to fit into a reply
sent over UDP. If that's not good enough you need a new RR type,
or a special label like _ssp. With a new label it is not more
trivial to cover wildcards at the unlabelled domain, you have to
decide what's most important. Apparently the SSP decision was:
"We might want lots of info" => "we cannot share an existing RR",
"it has to work with TXT" => "we need our own label", and after
these decisions wildcards are not more trivial, tough. But one
of the two premises ("lots of info") might be wrong, so far SSP
needs about 25 bytes - ignoring [FWS] for the moment, submitted
as "SSP issue".
The issue involving wildcards really demands that SMTP should
soon mandate publishing MX records to ensure message acceptance,
at least for IPv6 in 2821bis. : )
The Last Call ended 2007-12-24, and after five objections I did
not add this point again, and we failed to get support for this
2821bis issue :-(
You can't build TPA-SSP on two rejected ideas, 2821bis will keep
its ugly address fallback also for IPv6 / AAAA. It was a window
of opportunity because 2821 didn't mention AAAA explicitly, but
I saw to it that 2821bis does, so this window will be closed.
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html