Hi David,
At 07:03 02-05-2007, David F. Skoll wrote:
Actually, this would be generally useful, not just for a secondary MX.
The lookup could return more than one piece of information. For
example, it could say:
o This address will be accepted in a RCPT command.
o This address should be accepted in a MAIL command.
For example, we have an e-mail address "sales(_at_)roaringpenguin(_dot_)com"
that's only used for inbound mail; we never send mail from that
address. Being able to specify via DNS that MAIL
FROM:<sales(_at_)roaringpenguin(_dot_)com> is a forgery would be useful.
The idea here is to provide a mechanism to decrease NDNs generated
because the MX doesn't hold the recipient list (LDAP etc. methods not
feasible). This means rejecting during the SMTP phase. If a SMTP
client sends an email with "sales(_at_)roaringpenguin(_dot_)com" in the return
path and it fails recipient verification, the sender bears the brunt
of the problem. We are also not introducing any restrictions to the
current mail architecture.
I suggesting using this mechanism on the MX only to prevent it from
being used to whitewash a list of addresses. We also don't have to
deal with DNS attacks and DNS caching issues. Access control can be
addressed through DNS views.
As I see it, the zone holding the hash can be either at a provider's
end or near the final delivery point. One can use dynamic DNS or DLZ
to maintain the zone. You can even push updates through XFER. DNS
caching should not be much of an issue in such a setup. The zone can
be hosted on a DNS server different from the one for example.com.
In addition, allowing SMTP servers to more quickly reject recipient
addresses is useful; if an ISP can quickly reject a recipient based on
a DNS lookup rather than attempting an SMTP session, it can save
resources.
For Direct-to-MX, no third-party gets "hurt" as we are not sending
any bounces. In the case of the ISP, they'll have more incentive to
solve the problem at their end. After all, they sent the message and
they can easily track down the offending client and take whatever
action they see fit.
I'm not attempting to save resources as this may turn into
over-engineering and we'll have to consider a wider range of issues
(rate-limit DNS queries, hash reversal, etc.).
Why not? People operate RBLs with many thousands of entries and the
DNS handles it fine. A site with a lot of e-mail addresses *must* do
a directory lookup at some point, so it must have the infrastructure
to do it efficiently.
I expected that argument. :-) The people operating RBLs may be better
equipped to deal with thousand of entries. A large ESP may already
have a LDAP backend to do recipient verification. What we can do
here is to propose a simple solution for sites who do not have such means.
Regards,
-sm