-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Andy
Bakun
Sent: Friday, March 18, 2005 2:01 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] RE: rr.com and SPF records
On Fri, 2005-03-18 at 11:52, Scott Kitterman wrote:
To the extent that ESP has 100% uptime, you are right. I
currently list 3
companies mail servers in my record...
1. My ESP - I use this when connecting on the road and also if
I can't get
through using my DSL/Cable provider's MTA.
2. DSL Provider's MTA - My primary.
3. Cable company's MTA - I have a cable modem for backup
connectivity, so I
list their MTA for when I connect that way. (BTA, this is
Comcast and I HAVE
asked. They are clueless beyond belief).
Why not submit your email to your ESP all the time? Any Email Service
Provider has to be more receptive than a general provider like Comcast
to providing services like SMTP AUTH and submission on port 587. Last
time it was mentioned here, no one could find a provider who was
blocking port 587, and even if you could, an ESP should be willing to
let you submit on a different port and over SSL so you can use the
specific service they are providing you, since you are, presumably,
paying for it.
Generally speaking I submit it to either the ESP MTA or the "local" one
depending on my impressions of how the two are performing. I'm not blocked
either for port 25 or 587, so reaching the ESP mail server isn't a problem.
No system is perfect, but both my DSL provider and my ESP have pretty
reliable mail servers.
A system is only as strong as its weakest link. Using big consumer
grade services that everyone and their dog uses, like Comcast, to send
your email doesn't actually help a domain forgery situation. Unless
Comcast would do something to prevent cross-customer forgery (and if
they are clueless about using the submission port, they are most likely
clueless about avoiding cross-customer forgery also), listing them in
your domain's SPF record does not get you significantly close to a
strong forgery avoidance system.
You make severall incorrect assumptions here:
1. For sending mechanisms that are vulnerable to cross-customer forgery, I
put a ? in front of them to get a NEUTRAL result. I'm in SPF more for
discouraging spammers from using my domain (the SPF record ends in -all)
than for positive assurance of a PASS. I am interested in hearing about
services that do not permit cross-customer forgery, but haven't found one
yet the would work for me.
2. You make the assumption that my services are consumer grade. That is
true for the Comcast (but it's just a backup). My DSL is a business grade
service with good reliability.
You may believe that I don't need all this redundancy, but I do.
Then why rely on consumer level services? If email is that important,
then why not run your own MTA, which may be multi-homed for redundancy?
Then your domain's SPF record can list the IP addresses for your own MTA
and you never need to worry about your providers MTAs or their SPF
records. If email is important to your business, then presumably being
confident that your domain isn't being used by someone other than you is
also important.
As I said, the DSL is business grade. I could run my own MTA, but honestly
I've got better things to do with my time. What I know about running mail
servers is enough to convince me that I'm better off having someone who does
that for a living do it for me. And yes, being confident no one else can
get a PASS off of my SPF record is important to me. I don't believe it's
possible currently.
If I'm not
doing e-mail, I'm pretty much out of business.
If your ESP is not close to 100% reliable, then how are you receiving
email as reliably as you are able to send it? Do you only send email?
Or do your customers have to send to your address
@email-service-provider.com, @dsl-provider.com and @comcast.com in case
one of them happen to be out?
The MX is extremely reliable. I'm probably cursing myself, but at this
writing, it's been up for 230 days:
[Jul 31, 2004, 12:38 AM] servername Downtime
servername crashed while in service and was rebooted. Downtime was about
10 minutes.
If not being forged isn't important to you or your business, then don't
publish SPF records.
What would make you believe that's the case? All I said was that it's
reasonable to want redundancy in your permitted senders. Go dig up my SPF
record and explain to me how you think I don't care about being forged.
Scott Kitterman