ka at pacific.net
Fri Apr 3 20:53:10 IST 2009
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.
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
> 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.
Pacific Internet - http://www.pacific.net
More information about the MailScanner