On Wed, 17 Jun 2009, Franck Martin wrote:
I recently encountered the following question/problems.
I have a mail server and one of my users complains he is not receiving
emails from a domain. How do I find if I have blocked the domain from
sending to my server. Meaning, knowing the domain name of the sender,
how do I find the IPs from where the mail could be sent from. It seems
that SPF is the only tool to provide that answer?
In another related problem, which is linked to IPv6 and RBL. Buidling an
IPv6 RBL could lead to a huge database. Sure you can alleviate by using
"wildcards", but why not use the reverse DNS resolution to add a TXT
record associated to the IP to indicate the IP is the one of a mail
server? So any IP that does not have this record would be blocked for
SMTP. As IPv6 is not used for SMTP (or barely), this could be made
mandatory for IPv6 and optional for IPv4. An MUA could talk to an MTA on
port 25 because we know the the etwork range of the MUA or the
alternative is to use the new mail submit port.
I predict that no significant amount of mail ever originates from IPV6.
Because it would be impossible to maintain a DNSBL for IPV6, I expect that
enough sites will decline all IPV6 mail that it won't pay to send from it.
Consider that because a spammer could (spoof) a different IPV6 address for
every message, even a different 48 bit block for every messages, MTAs will
be left with only content analysis for spam blocking. I don't expect IPV4s
will ever be so scarce that enough MTAs will start using them out of
necessity - ISPs will give each customer 4 IPV4 addresses with their
million address IPV6 range, and customers will use those 4 addresses for
the things that really need IPV4 - such as internet facing MTAs.
Consider also the difficulty facing the first IPV6 only MTA. It's
connectivity will be very low, even compared to the worst possible
allocation of a former spammer block in IPV4. It is one thing to put up a
little used IPV6 web site - there isn't much of a penalty for adding IPV6
to IPV4. And eventually some special purpose websites will be IPV6 only,
those that know their clients are IPV6 only. But there isn't any point in
a public-facing IPV6 MTA without an IPV4 alternative. And since the IPV4
alternative can serve the IPV6 clients just as well, it will never be very
usefull to add IPV6 support.
This is a prediction, not a prescription.
Daniel Feenberg
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg