OT: Question

[Ken A]

Kevin Miller wrote:
> Ken A wrote:
> 
>> Why not use it? It's usable only if you understand it, and it can
>> be 'inconvenient' for customers to have to send through a defined
>> list of outgoing servers.
> 
> Um, maybe I'm just a lot slower than the rest of you, but I think
> "It's usable only if you understand it" applies to
> sendmail/postfix/MailScanner, etc. just as well.  That's why we're
> not being paid minimum wage.  This job requires a bit of thinking.
> If set up right on the back end, there's very little the customer has
> to do.  For a customer to send, they *have* to configure their mail
> client with an outgoing server.  The mail has to be sent somewhere.
> If they can figure out how to set up their client, what's the problem
> w/them picking a specific set of email servers?  

That is a good question. But I answered it. It's inconvenient. Customers 
may have more than one ISP, more than one business, more than one domain 
hosted, parked, here, there, etc. They switch their From: address in 
their email client depending on many things, but they leave their 
outgoing server the same. Yes, MUAs could do a better job of tying 
outgoing mail server to the From: address chosen.

Currently, asking customers to _not_ send through some other mail server 
when they are borrowing a computer, or using their whatever mobile 
device on some crippled cell network is inconvenient for the customer. 
ISPs operate on a fairly slim margin these days. Support calls can doom 
an ISP. If SPF was a silver bullet, it might be worth pushing it on 
users, but it's not.

Ken



Since most servers
> are set not to relay, they're limited to a defined set of servers by
> definition, no?
> 
>> ISPs, web hosts, a large number of mail server admins (myself 
>> included), cannot set hard fail for most small business domains. 
>> Customers expect email to _work_, and they send from a number of 
>> locations using a number of systems (work, home, library, college, 
>> etc). Setting hard fail will only generate calls to your support
>> desk unless customers understand the implications.
> 
> Um, yeah.  Not sure what's so hard about that.  If I'm off at some
> remote location I access my email via a web interface.  OWA, at work,
> and my ISP's squirrel mail for home email.  Mail sent from there goes
> out one of my servers and the user neither knows nor cares which.  If
> I needed to send via an interface other than the web I'd configure
> auth on the mail server.  If a user can enter a server name when they
> configure the client, they can surely enter their username/password
> in the same configuration dialog.  Or am I missing something?
> 
>> Wouldn't it be great if customers read about SPF on the support 
>> section of your web site, and were thrilled about it? Reality 
>> check... Most customers do not care about SPF, and have no interest
>>  in learning about it unless it can benefit them in some immediate
>> way - if their domain is being actively spoofed, for example. In 
>> practice, this rarely happens.
> 
> Users don't need to know about SPF.  The mail admin does.  When the
> user gets an account, you give them instructions on setting up their
> client.
> 
> In practice, domains are often spoofed.  My users are frequently
> joe-jobbed.  I've set SPF to hard fail.  None the less, I still see a
> number of NDRs coming in.  One of my users got over 500 of them
> yesterday.  That was an anomaly, but it could have been prevented if
> the remote servers had just checked my SPF records before accepting
> and bouncing the mail.  Even if people don't publish SPF it is quite
> easy to check for it, either in spamassassin or a milter.
> 
> I just don't see what's so impractical about SPF.  It's not a
> cure-all, but it stops a lot of the noise and would stop more with
> just a little thought and planning.
> 
> YMMV...
> 
> ...Kevin


-- 
Ken Anderson
Pacific Internet - http://www.pacific.net