Douglas Otis wrote:
DKIM requires acceptance of the message body.
Obviously. Receivers will still reject messages before DATA
where that makes sense from their POV, e.g. because they use
services explained in the ASRG SIQ and DNSBL drafts, or in
the ASRG LMAP draft, i.e. what is now RFC 4405 and RFC 4408.
Hector's SMTP HEAD draft offered a kind of compromise between
before vs. after DATA, but it won't help with DKIM, and it's
not clear how to combine it with the "selective reject" I-D.
DKIM's ability to offer reliable indications of misbehaviour
will bolster that of content filtering results.
DKIM without SSP (or similar) doesn't have such ability.
DKIM can help overcome problems created by the unreliable
application IP address path registration strategies.
DKIM doesn't come near to the envelope sender address, we
made sure that it doesn't depend on SMTP. Backscatter is
mainly an SMTP issue (+ RFC 3798 + 3834 + sieve vacation).
DKIM can prove helpful at restoring integrity to SMTP,
even after the dot. : )
DKIM operates on messages (SDU, 2822), not on envelopes
(PDU, 2821). You can use DKIM on the other side of a UUCP
link if you have access on DNS, or whereever you find a
"fresh" message/rfc822 (e.g. as MIME part), it's not based
on SMTP. For various reasons DKIM does *not* try to solve
the SMTP issue backscatter.
The "everything at once" approach represents a potential
overhead that can well exceed that of accepting messages.
Receivers are free to say "enough already" when it pleases
them, in fact they MUST and SHOULD do this (RFC 4408 10.1).
IMO "a", "all", "include", "ip4", "ip6", and "redirect" are
essential for a simplified SPF. The "ptr" is no problem,
the Authentication-Results I-D offers a similar test with
similar processing limits.
The "exists" is rather exotic at the moment (in theory SES
is a nice idea), and tossing %{l} out, or maybe limit "mx"
to at most one per record, because the original RMX idea
makes sense, might be possible in a 4408bis.
Nobody is going to learn new TPA-SSP tricks from scratch,
unless you go to draconian simplifications like "nobody
must send from an MTA to an MX of a 3rd party, when that
MTA isn't listed as MX of the sender". This just won't
fly, no matter how long we could argue that it's the idea
of an STD 10 "MX" - I'm not even sure that it's the case.
reliance upon unreliable IP address path registration
can and should be avoided.
Without time travel and removing RFC 1123 5.3.6(a) before
it was published all you can get is "BTNRP", better than
no reverse path (i.e. SPF). If some senders get their
"permitted IP enumeration" wrong that is no problem for
receivers, it's a problem for these senders, they fix it.
[MS issue with new RR types]
MS might even view demise of DNS an advantage, as their
alternative is heavily patented.
Sometimes they're forced to adopt standards if they don't
want to lose market share. Does this issue still exist in
Vista, or does it only affect XP and older MS platforms ?
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".
Concerns remained regarding enterprise support of new RRs.
We all know that the SPF RR has an "MS-compatible" sibling.
At the moment "sender policy framework" stands for "we can
do 'sender permitted from' or even 'purported responsible
address', and HELO", not much for a wannabe-framework. It
is kind of obvious to add SSP *IFF* it fits. RFC 5016 tries
to make sure that it won't fit (5.3 point 5), but IMO nobody
cares about cryptic abbreviations in a text-like DNS record.
Of course it is good to use readable and/or intuitive terms
while talking about such abbreviations... :-)
SPF now demands at least 10 linked records be permitted
for each name validated.
You can have *at most* 10 "redirect". As you well know, I
deleted various synonyms for "intentionally telling what is
known to be not true". If you eat up the overall limit 10
for "redirect" you have no "a", no "mx", no "include", etc.
The "redirect" is a v=spf1 and spf2.0/* feature, adding SSP
to the SPF RR introduced by say v=ssp1 would define its own
syntax, for 25 bytes it doesn't need a "redirect" feature -
it would need the 25 bytes in the RR set (shared with SPF).
The impact of IPv6 may cause this sequence to be further
extended
Nonsense, with ten "redirect" you have at least 4500 bytes
to enumerate permitted IPs. You can and should aggregate
them to CIDRs, it is no problem if you permit many IPs which
are never sending mail as long as they are your IPs or known
to behave.
Besides this "redirect" business has nothing to do with SSP:
Assuming SSP does share the SPF RR, and that for a given
SPF RR set the v=spf1 and spf2.0/* records already use the
UDP limit (~450), then it would be necessary to split one
of these v=spf1 or spf2.0/* records with "redirect" to make
room for the 25 bytes in a v=ssp1 record. They could also
decide that the PRA experiment is now finished and pull the
spf2.0/pra record to make room for v=ssp1. After all SSP
is supposed to be "better" than spf2.0/pra, isn't it ? Of
course I'm not convinced that "1st author" is a sound idea.
Using SPF to validate a DKIM domain in some manner might
then impose this 10xplus sequence for each of several
possible signatures.
Nobody proposed to use SPF to "validate a DKIM domain in
some manner". SPF validates envelope sender addresses, it
allows "accept and bounce" after a PASS. SPF is for SMTP,
not for DKIM. If you reject a SSP FAIL at your border you
don't need SPF, neither the protocol(s), nor the record(s).
I proposed to put the SSP info into a separate DNS record
in the existing SPF RR set. You don't need to look at any
v=spf1 or spf2.0/* record after a query=spf, you'd look
for the v=ssp1 record.
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 :-(
While not imposing change when consensus is not clear is
understandable, a lack of a discovery record for assured
acceptance can lead to serious DNS related risks.
Let's say that there are still more pressing problems with
DNS attacks than your idea to abuse SPF to query addresses
in ten MX sets. RFC 4408 is still the only RFC I'm aware of
mentioning that MX queries can be an issue, with MUSTard and
a SHOULD to mitigate it. If that turns out to be not good
enough 4408bis will have to fix it, e.g. as noted above.
The entire email policy concept is affected, not just SSP
or TPA-SSP. The alternative for asserting policy without
an assured discovery record is to walk the DNS tree for A
or AAAA records. The lack of a specific discovery record
represents a serious architectural extensibility defect
for SMTP!
Yes, that's what SPF is for. Trying to "reinvent" it again
is a dubious plan, simplifying it is more attractive.
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html