On Thu, 2004-07-08 at 11:51, Greg Connor wrote:
--Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
From this definition of forgery, it would appear you are not referring
to Sender-ID. This is important as Sender-ID is changing the scope of
this protection. The ASRG definition was based on an effort to reduce
mail traffic by examining RFC 2821 information. Sender-ID uses RFC 2822
information and, as such, will not impact mail traffic.
This point assumes that mail traffic will continue at the same level, even
when messages are being rejected post-data. Spammers don't want to spend
time and bandwidth on a losing transaction any more than receivers do. I
assume the opposite: that when forgeries are being detected (even after
DATA) that the traffic causing the failed messages WILL go down. This is
based on the idea that spammers will adapt in order to get their messages
through.
Trojans sending much of the viruses (for more Trojans) and spam (for
revenue) are not concerned about full compliance to a specification, nor
do they implement proper states for an SMTP client. Why attribute abuse
to malevolent intent when expediency is more likely a principle
motivation. So stopping a message after wasting the full bandwidth of
the rejected message may seem like a small concern, but there may be
another 100,000 more of these Trojans requesting service. The extra
bandwidth to get them to leave is never recovered by their rejection.
In addition, many of these spammers use a technique that appends a
random sub-domain resolved using a wildcarded record as a means to
obfuscate filters. It also means data needed for a repeated visit or a
repeated message will not be in a DNS cache. A loss of even more
bandwidth on the DNS queries, possibly more than from the messages being
checked.
If a DNS server holding MARID information isn't robust, then it will
most likely also fail for MX records, in addition to MARID records.
The rate that a Sender-ID SMTP receiver queries DNS versus that needed
to find an MX server by the SMTP sender are significantly different in
terms of both the number of queries and the serial sequence required.
The loads and delays are not comparable to allow such an analogy to
dismiss these concerns.
I think the previous message was referring to MX records being looked up by
the receiver (to see if the sender's MX is 127.0.0.1 for example).
I believe most MARID DNS queries will be 1 or 2 per transaction and can be
cached easily. I have seen nothing to suggest that the relationship is
other than linear. Therefore I dismiss "these concerns" which seem to
suggest that the relationship is geometric or exponential or whatever. It
doesn't make sense, and is not borne out by the early adopters of SPF.
Could you explain the premise used for this assumption?
I don't see how "robustness" matters more for DNS when it contains
MARID records than when it doesn't. Sure, more records are being
looked up in DNS, but many MTA's already do MX lookups when receiving
mail "from" a domain, in an attempt to implicitly discover the domain
owners intent, even when there's no standard saying that they should
do this.
Scale and Scope
The complex linked nature of these records becomes important as this is
indicative of limitations Sender-ID has with respect to scale. An MX
record only refers to a set of hosts that "receive" mail for a domain.
As SMTP allows this mail to be relayed, there may be many times this
number of hosts that "send" mail for the same domain. In addition, all
other domains that may originate mail on behalf of this domain are to be
expressed by this Sender-ID record set. In addition, these records also
reflect other domains that may also share these hosts. An MX record is
never expected to be so expansive in scope nor is comparative to the
potential size of such a response. This still excludes the "added"
features. : 0
Hmm, this paragraph also seems to contain high FUD-to-fact ratio.
Sending hosts > Receiving hosts (increases scale and scope)
Originating domains > Receiving domain (increases scale and scope)
Receiving Domain sets > Receiving domain (increases scale and scope)
What are you disputing by making such a statement?
My premise is that abuse of published partial lists left open will
ensure either the removal of these records, or an attempt to fully
publish a comprehensive record set. A desire to delegate to other
domains providing services runs the risk that as they add a few
indirections, this may cause hard errors and the complete loss of mail
service without the administrator of the domain having done anything
atypical or perhaps having done nothing.
Or, do you see Sender-ID as having an amplification problem? e.g.
If MARID queries increased super-linearly with the number of
connections. If so, it would be a serious flaw in the proposal.
Serious indeed.
Hmm, in that case I would be interested to see any information that leads a
reasonable person to believe that the relationship is not linear. (hint:
y=20x is a linear relationship.
In reference to the information added to the core document
http://www.ietf.org/internet-drafts/draft-ietf-marid-core-01.txt
Pg. 18:
5.4 Recursion Limitations
Evaluation of many of the mechanisms in section 5.1 will require
additional DNS lookups. To avoid infinite recursion, and to avoid
certain denial of service attacks, an MTA or other processor SHOULD
limit the total number of DNS lookups that it is willing to perform
in the course of a single authentication. Such a limit SHOULD allow
for at least 20 lookups. If such a limit is exceeded, the result of
authentication MUST be "hardError".
MTAs or other processors MAY also impose a limit on the maximum
amount of elapsed time to perform an authentication. Such a limit
SHOULD allow at least 10 seconds. If such a limit is exceeded, the
result of authentication SHOULD be "transientError".
Domains publishing records SHOULD keep the number of DNS lookups to
less than 20. Domains publishing records that are intended for use
as the target of "indirect" elements SHOULD keep the number of DNS
lookups to less than 10.
Using an assumption that Sender-ID records are able to limit the
required queries to 10 and set the "transientError" timeout at 10
seconds, what will be the impact on network integrity?
The transport for SMTP uses TCP, but now Sender-ID interjects 10 UDP
queries per message that "must" occur or the connection suffers a
temporary error event requiring a repeat of a message transfer. The
default for a resolver lookup timeout is typically set to 5 seconds (a
minimum of 2 seconds) as RFC 1035 recommends, where 10 seconds is
considered worst case. Should there be a another timeout, this limit
often doubles. The connection is tasked with making 10 UDP queries
within 10 seconds however.
Should the network suffer a 5% packet loss rate, then 1 packet will be
lost on average within these 10 lookups. This will invoke the 5 second
timeout which then reduces the time for the remainder of the queries
(possibly leaving half a second apiece to resolve each new query).
Depending upon the distribution of lost packets, the connection could be
lost after reception of the first message, only to be retried again
later and could make a large transfer of messages impractical. TCP used
for SMTP could deal with this packet loss rate, but because of Sender-ID
and these many queries with a short timeout, the integrity of SMTP is
significantly reduced.
If the timeout are restored to normal limits for these DNS queries,
Sender-ID may dramatically reduce performance of the SMTP server and the
reason for imposing the hazardous time constraint. The trade-off
becomes either a possibly dramatic reduction in performance of the SMTP
server, or a dramatic reduction in the network integrity for the SMTP
server during times of network congestion. The use of the RFC 2822
identities for Sender-ID means messages are transferred regardless
whether they become rejected. A loss of integrity will then add to
network congestion and thereby possibly leading to a collapse of the
network due to the non-linear effect caused by congestion, redundant
transfers by Sender-ID, and the reduced network integrity.
-Doug