Re: [Asrg] What are the IPs that sends mail for a domain?

[Daniel Feenberg <[e-mail]>]

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



>