"J.D. Falk" <jdfalk@cybernothing.org> wrote:
On 09/07/04, Paul Jakma <paul@clubi.ie> wrote:
Then there's Sender-ID. Bulky XML in DNS, sigh.
No, that was CallerID. SenderID uses a format that looks and smells almost exactly like SPF.
I only mention this to reduce the FUD.
Sender-ID requires the processing of a minimum of 10 TXT scripts that can reference dozens of A, AAAA, MX, PTR, CIDR notation for IPv4 & IPv6 addresses, construct labels from various message fields, invoke redirections, includes, "exists" macros, and specify both "Pass"/"Neutral" open-ended lists, where each script is provided a total of 20 seconds. In addition, the draft requires undocumented extensions be ignored, even at the released revision level. Such amounts of DNS lookups of "who knows what" may easily exceed normal mail traffic, and, with the 20 second timeout (200 second total), it is unlikely exponential UDP back-off will be obtained. XML would have made it worse, but that does not mean there is little reason for concern. By simply authenticating the MTA EHLO and establishing a name, a mailbox domain to MTA name relationship, as a name list, can be established within a single DNS lookup without the use of script. Importantly, the EHLO establishes a name that does not assume mail channel integrity to be useable for reputation assertions. Such a mailbox domain to MTA name list would not force the use of specific RFC2822 From mailbox domains, as it would be independent of the MTA authentication. Such a name list would not expose users to harm by both being spoofed and then having their mailbox domain blacklisted by reputation services mistakenly trusting Sender-ID. There is nothing within Sender-ID that indicates an MTA is shared, or that Sender-ID was checked. -Doug