[Mimedefang] Deadline for SPF records *long w/morbid horoscope*

[Jeff Rife]

On 12 Aug 2004 at 10:20, Cor Bosman wrote:

> > In any case, this is in reality no different from a client calling up 
> > and getting the mail from a server.  Because the ISP is the only MX, it 
> > should know about all the deliverable addresses, simply to avoid 
> > dictionary e-mailings to these "offline" domains.
> 
> In theory this sounds fine, in practise this is irrealistic.
> Im assuming you dont run an ISP?

The company I work for provides Internet services to clients.  If you 
want to use your own mail server, you can, and e-mail goes directly to 
you through our link to the Internet (in other words, we provide 
connectivity only).  If not, our server is MX and you give us the list 
of valid e-mail addresses and retrieve via POP (no IMAP because we 
don't want to be storing all their e-mail).  You can have a server of 
your own to distribute e-mail, but you must get it off our server using 
"client" tools (like fetchmail or any MUA).

The result is close to zero bogus e-mails hitting the postmaster 
account(s).

> > I think I confuse ISP with "quality ISP".
> 
> There is no need to be abusive to try and make your point. It makes your
> point seem less valid.

I'm not being abusive.  More and more ISPs are heading towards things 
that reduce network abuse.  One thing that does is having the full list 
of legal addresses on the answering MX.  This is obviously more work 
for them in some ways, but the work it saves is worth the trouble to 
them and it has the nice side effect of reducing work for *other* 
Internet users.  That's being "quality" or "responsible" in my book.

> And what do you think the command ETRN is for?

It's an optional part of SMTP that doesn't have to be supported, and 
does have some security issues.

>                                                 One could give these
> hosts a lower MX, but on the other hand, if they're almost never
> online you'd have to wonder if thats a good thing. 

If they are almost never online, they are "clients", not servers, so 
they need to be treated as such.  Harsh, I know, but treating them as 
clients in other ways (forcing them to use your server through the MSP 
port instead of the MTA port, for example) goes a long way to 
combatting network abuse.

>                    This discussion started with implementing SPF, and
> for an ISP implementing SPF has a lot of problems. Not unsolvable,
> but it wont be pretty. 

On that, we agree.  The biggest issue I see is the return-on-investment 
for making sure that everything is correct.  In some cases, many just 
won't do things 100% because the "goal" (spam-reduction) doesn't seem 
to be something that SPF really will do.


--
Jeff Rife        |  
SPAM bait:       | http://www.nabs.net/Cartoons/OverTheHedge/HDTV.gif 
AskDOJ at usdoj.gov |  
spam at ftc.gov     |