On 6/28/04 5:56 PM, Hallam-Baker, Phillip sent forth electrons to convey:
<>
Caller-Id required a single packet in each direction for the vas[t]
majority of mail interactions.
<snip>
Please watch your tone.
That's incorrect. Please read the earlier post to this thread at
http://www.imc.org/ietf-mxcomp/mail-archive/msg02198.html
as it argues that this is not the case.
I fail to see the connection between an argument that a 20%
That's not what I'm talking about. Consider the whole post,
particularly paragraphs 1-3. Arrgh.
The URL is above.
That is an issue that calls for a security consideration, not
hysterical subject headers.
Ah, that's what set you off. Please address paragraphs 1-3 or don't
respond.
BTW, I wonder if it would make sense to specify that caching
DNS servers
MAY cache LMAP records for x hours, even if they have a short TTL.
This would reduce DDoS exposure. At what cost, and what's a good x?
Without this, it's appropriate to assume that the attackers
will publish LMAP records with TTLs ~= 0.
How about simply stating that if a MARID record is retreived and
determined to be malicious an MTA SHOULD consider caching that
conclusion?
An alternative with pluses and minuses.
If malicious.com or compromised.com have a malicious record in
their DNS it should become apparent quite quickly.
I don't see how. Say 9/10s of a domain's record resolves. How is this
domain identifiable as malicious?
Maybe it's just under attack.
Also remember that the sender has to be holding an open TCP
session during this process with a known source IP port. This
is not exactly an anonymous attack.
Again, how is a malicious actor identified automatically?
Even if the attack is comming from a zombie, it is worth at
least a thousand packets to be able to determine that there is
a likely zombie on a network somewhere. No more spam from you,
plus report it to the sysadmin responsible.
MARID provides additional motivation for DDoS against the DNS.
The argument makes no sense unless you can state which part of the
DNS is going to be attacked and how such an attack would make it
easier to send spam.
Same way taking down BLs works. It makes 'em problematic (e.g
unreliable and/or very resource intensive), so folks stop using 'em.
The attack that appears likely to me would be for the attacker to
send a stream of DNS queries to sender.com which appear to come from
receiver.com so that sender.com decides to stop responding to
requests from that site, then broadcast a stream of spam.
Seems to me that any such attack has the problem that the attack
and likely motive become immediately obvious to sender.com. All
we need to do is to work out a way to close the loop.
And how do we do that?