[lug] SMTP delivery: No route to host

[Nate Duehr]

On Wed, 2002-11-27 at 06:27, Michael Shuler wrote:

> They don't know any different until they get blacklisted and mails start 
> to bounce.  Then I get calls from everyone else on the network, some of 
> them very dilligent and security conscious, that also got blacklisted 
> because of the common practice of the bl folks to indiscriminately list 
> the entire /24 or /16.  The bl maintainers are, generally, quite 
> difficult to work with, with regards to removing IPs or subnets.  It 
> usually takes begging to even get a reply.

I always try to educate server admins about these "bad apple"
blacklists.  They're really bad to use if they don't respond to
resonable requests to unlist things.  Unfortunately most of them are
this way now.

> An advanced method of mailserver identification and auth would be a 
> great step in the right direction.
> 
> > Why aren't the largest ISP's lobbying for stricter laws?  Because
> > they're using spam filters as MARKETING FODDER.  "Use
> > AOL/Earthlink/Idiots-R-Us!  We'll protect you from the big bad
> > Internet!"
> 
> Filtering and blocking is fine as a temporary bandaid.  The problem is 
> that both methods are still processing the mail, using precious cycles 
> and bandwidth.

I just hate it that this is considered a "plus"... it *has* to cost
those guys more to filter it in the long-term than to fight it properly
in the political and legal realm.  Higher (much higher) fines on this
stuff would get more lawyers involved (once they realized they could
possibly "hit the jackpot" if they could win a big case).  Some states
have very tough spam laws, but the monetary damages one can claim are so
low that no lawyer will take the case on a contingency basis.

> I cannot really think of how to approach a modern mailserver handshake 
> that could be utilized to this end, but Nate has peaked my interest.

It's been an interest of mine for a while, the problem becomes who holds
the trust database... like a CA.  I guess that'd be one step -- servers
could exchange standard SSL keys and communicate over SSL... then you'd
have some mail that was from "known" sources in the headers and could
have the standard mail server stuff still on for a while in a transition
period... but I think the hassle of setting something like this up is
higher than most admins would go through unless there were a lot of
"excitement" about it...

It's a tough nut to crack, for certain.  Because server-to-server
identification and then eventually authentication is just the start...
then the clients need to be doing it.  Although most clients now support
TLS, etc...

-- 
Nate Duehr, WY0X  (AIM: BigNateCO)
nate at natetech.com