Outgoing SMTP Servers

Douglas Otis dotis at mail-abuse.org
Tue Oct 25 23:37:37 UTC 2011

On 10/25/11 12:31 PM, Ricky Beam wrote:
>  On Tue, 25 Oct 2011 12:55:58 -0400, Owen DeLong <owen at delong.com>
>  wrote:
> > Wouldn't the right place for that form of rejection to occur be at
> > the mail server in question?

>  In a perfect world, yes. When you find a perfect world, send us an
>  invite.

> > I reject lots of residential connections...
>  The real issue here is *KNOWING* who is residential or not. Only
>  the ISP knows for sure; and they rarely tell others. The various
>  blocklists are merely guessing. Using a rDNS name is an even worse
>  guess.

Agreed.   Don't expect a comprehensive list based upon rDNS containing 
specific host names with IPv6.  That would represent a never ending 
process to collect.

> > However, senders who authenticate legitimately or legitimate
> > sources of email (and yes, some spam sources too) connect just
> > fine.

>  Authenticated sources can be traced and shutoff. If a random
>  cablemodem user has some bot spewing spam, the only way to cut off
>  the spam is to either (gee) block outbound port 25, or turn their
>  connection off entirely. As a responsible admin, I'll take the
>  least disruptive path. (I'll even preemptively do so.)

Blocking ports is not free, but don't expect all DSL providers to 
unblock port 25 unless it is for a business account.  Price 
differentials help pay for port blocking.

In a perfect world, all SMTP transactions would cryptographically 
authenticate managing domains for the MTA.  With less effort and 
resources (than that needed to check block lists) IPv6 could continue to 
work through LSNs aimed at helping those refusing to offer IPv6 
connectivity.  Blocking at the prefix requires block list resources 65k 
times greater than what is currently needed for IPv4.  IPv6 
announcements seem likely to expand another 6 fold fairly soon as well.

In comparison, cryptographic authentication would be more practical, but 
a hybrid Kerberos scheme supported by various third-party service 
providers could reduce the overhead.  Is it time for AuthenticatedMTP?


More information about the NANOG mailing list