North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Spammers Skirt IP Authentication Attempts

  • From: Douglas Otis
  • Date: Wed Sep 08 02:41:21 2004

"J.D. Falk" <[email protected]> wrote:
> On 09/07/04, Paul Jakma <[email protected]> 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