ietf-mxcomp
[Top] [All Lists]

Re: Why XML

2004-06-23 01:58:09

On 6/22/04 8:37 PM, Douglas Otis sent forth electrons to convey:

...
Any mechanism introduced that stems the flow of UCE will be subjected to
intensive attack.  Introducing a required series of DNS queries to
establish permissions increases a data footprint, but also code size may
also adversely impact system resources depending upon OS and structure. If used in the normal fashion, no parser is required to utilize DNS
answers, so the introduction of a parser increases vulnerabilities.  The
less rigid and more extensible the syntax, the greater the
vulnerabilities.  As the allowable answer from DNS is small, any chained
records further increases vulnerabilities by increasing both resources
and time required to process a message.

An attacker "jamming" the checking mechanism might set up DNS servers
for domains they control that respond erratically and offer complex
record sets with small TTLs.  The attacker then sends messages from
their domains in an attempt to exhaust resources as a means to have
recipients disable the checking processes within the channel.  If on
average a small enterprise uses two outside services, then normally
there will be a need to chain these records as it would be prohibitively
difficult to administer otherwise. These outside vendors may in turn
also outsource for yet more chaining.
As example, a mail server is receiving 50 messages per second that
average 4 K bytes in size.  If using the SPF/CID mechanism, checking DNS
data is indeterminate as there is no limit for the number of sequential
queries required to converge upon an answer. RFC1035 indicates 5 to 10
seconds should be considered a worst case resolver interval.  If there
becomes an average of 10 queries with an average of 5 seconds a query,
then this limits each process to about 1 message about every minute. These 10 queries will also add to the traffic at 350 bytes per record a
total of 4K bytes of additional traffic for a doubling of the network
load.  The mail server may normally handle 1,500 simultaneous processes,
but at 60 seconds per process, the mail server is reduced to only
running 25 messages a second.  This may still represent the same amount
of network traffic, just half as much mail gets through the network.
...
My mail server already checks over a dozen RBLs, plus doing Razor, DCC, and slews of header and body regexp checks. If MARID is effective enough for long enough that most spammers give up, then ....
This will be more realistic:

As example, a mail server is receiving 50 messages per second that
average 4 K bytes in size.  If using the SPF/CID mechanism, checking DNS
data is indeterminate as there is no limit for the number of sequential
queries required to converge upon an answer. RFC1035 indicates 5 to 10
seconds should be considered a worst case resolver interval.  If there
becomes an average of 4 queries with an average of 1 second a query,
then this limits each process to about _ message about every minute. These 4 queries will also add to the traffic at 50 bytes per record a
total of 0.2K bytes of additional traffic for a halving of the network
load.  The mail server may normally handle 1,500 simultaneous processes,
but at 4 seconds per process, the mail server has spare capacity up to
'only' running 4000 messages a second. Of course, CSV queries are efficient even if most of the queries are against spammer domains.

Also, you're assuming there are no DNS cache hits.

Also, if an SPF query starts with a blacklist check of the domain and that fails, then no further queries will be made. That's efficient. But yeah, spammers trying to gum up the works will result in what you're talking about.




<Prev in Thread] Current Thread [Next in Thread>