Caller-Id required a single packet in each direction for the vas[t]
majority of mail interactions.
Please watch your tone.
That's incorrect. Please read the earlier post to this thread at
as it argues that this is not the case.
I fail to see the connection between an argument that a 20%
increase in data size due to use of XML is significant and
the current claim that we risk bringing down the Internet
with Sender ID.
I don't see you addressing the concerns Doug raised.
There is a proof point here that it is possible to encode the
hotmail IP addresses in three packets of data, most records in
Ergo if we end up with something that is dramatically worse
than that, like an order of magnitude out there is something
really wrong with the protocol we have come up with.
Perhaps you were arguing that all mail servers should rely on local
caching DNS servers that will cache all the word's active
If that's the case, then *perhaps* that does present a strong DDoS
defense. Please confirm/flesh out. Does it work in the face of
malicious macro SPF records?
Only if we decide to support the macro interface. I was hoping that
we would reject it on the grounds that all the use cases that have
been stated can be implemented anyway.
If what you are trying to say is that there must be some limit to the
complexity of a query I think that is correct, clearly it is a bad
thing if records branch out indefinitely.
That is an issue that calls for a security consideration, not
hysterical subject headers.
BTW, I wonder if it would make sense to specify that caching
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
If malicious.com or compromised.com have a malicious record in
their DNS it should become apparent quite quickly.
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.
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.
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.