OT: Question

[Kevin Miller]

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?  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
-- 
Kevin Miller                Registered Linux User No: 307357
CBJ MIS Dept.               Network Systems Admin., Mail Admin.
155 South Seward Street     ph: (907) 586-0242
Juneau, Alaska 99801        fax: (907 586-4500