Douglas Otis wrote:
Of course, the TXT RR at the base domain does not scale and should
be avoided. : )
Yes, that's how we arrived at type 99, or here at _whatever labels.
Per the current SSP 41 byte string of "v=ssp1 dkim=strict
handling=process t=n:s" a total of 54 bytes is needed
IIRC I counted only "dkim=strict handling=deny" when I wrote "25",
but the syntax could be trimmed if necessary to squeeze this info
into another RR elsewhere with its own size limitations. So far
nobody thinks it's necessary, but we're not yet ready with Dave's
two related issues.
When more than two different protocols utilize the same TXT RR
and location, newer versions are unlikely to remain viable.
Yes. On the "SPF devel" list folks discussed that the UDP limit
will be soon anyway obsolete (= not good enough for IPv6).
If you don't ignore it you get 112 instead of 111. I've no
idea what reporting records are.
SPF has an exp mechanism to fetch a macro expanded messages
that could be added to a DSN.
ACK, with that you can get 113 as worst case. JFTR what that
means: A receiver tried q=SPF (TXT), and after getting nothing
q=TXT (SPF), or some variation counting as 2 queries. After
that the sender policy contained 10 mx mechanisms (or 9 mx +
1 ptr), more would hit a MUST NOT, so we are at a total of 12
queries. Each mx (or the ptr) stays at the limit of 10 names,
more hits another MUST NOT, for at total of 112.
After that the final outcome is FAIL, therefore the receiver
could fetch an exp= modifuer record arriving at 113 queries.
An exp= does not hit the limit 10, because reporting a given
FAIL is more important than whining about the 11th exp= query.
I certainly agree that a policy with 9 or 10 mx can't be sound.
The intention in RFC 4408 is to make these limits very simple
to understand (count to ten, no matter what), and to arrive at
reliable limits (for sound non-attacking policies), i.e. if a
policy violates these hard limits all SPF implementations are
supposed to treat it as broken (PermError).
It wasn't the intention to sanction "9 or 10 mx" as remotely
plausible: For starters that would be at odds with a general
SHOULD following the three MUST NOTs for "ten". I said this
before, it's perfectly okay if 4408bis introduces additional
limits. As long as implementors understand what the purposes
are (not only anti-DoS, also reliable PermError) it's fine.
The macro expansion of SPF records to evaluate DKIM related
email-addresses must be avoided.
SPF could offer an SSP-shortcut anyway *IFF* that makes sense
for enough receivers supporting both.
the limit of 10 names per mx-mechanism is a hard RFC 4408
limit, it is no limit of "MX records themselves".
However, size constraints of MX responses provides roughly
comparable limits.
Yes, that is how Wayne (the co-author) arrived at this "ten",
and we were aware that some domains have as much as eight MXs.
It is also unlikely that call back verification will rapidly
attempt to resolve all MX targets that are within different
domains.
CBV is used for the decision to accept a given MAIL FROM, it
has to be fast (within the relevant timeout of the SMTP client).
It would appear DKIM helps solve your concern about forwarding.
My concerns are somewhat limited to "I got one pseudo-551 caused
by an SPF FAIL after traditional forwarding since May 2004", and
I'm not aware of any case where MAIL FROM me vanished in a black
hole for the same scenario but accepting FAIL as "suspicious".
Of course others consider this as serious problem. Likewise I'm
not much concerned about DKIM's potential mailing list issues,
and for SSP the caveat is clear enough.
I am in even in favour of eliminating acceptance when there are
no MX records.
If that flies (as a future common practice) describing it in an
RFC would be simple. For the other way around, an attempt to
introduce it in an RFC, I doubt that "they" will let you try it.
But I like the idea (outside of 2821bis).
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html