On Fri, 26 Aug 2005, Dan Field wrote:
About the most holy RFC 1123. With that regime, any bozo
anywhere in the world
can start forwarding stuff to me without my asking them too. And they
do. It is a *feature* of SPF that those bozos get rejected.
If I really did ask them to forward stuff to me, I'll list them.
And how about the local business who has one PC, has his company domain name
with a local hosting company but has his e-mail forwarded to his dial-up
ISP's account. There are thousands upon thousands of these people.
It sounds like he really did ask for that forward.
His ISP then implements SPF checking, which is perfectly reasonable for them
to do... but whenever he is sent an e-mail from a company with a strict SPF
policy, and is then forwarded by his local hosting company he is going to
have problems isn't he?
If the SPF checker lists his forward - no problem. If the dial-up ISP has no
mechanism to list forwarders, then they don't reject on SPF. Again - no
problem. If they have no mechanism to list forwards AND reject on SPF,
well we all screw up big time now and then.
Its all very well you saying "If I really did ask them to forward stuff, I'll
list them" when you technically know what you are doing, but the majority of
people using e-mail do not know anything about the technicalities... if it
doesn't work they don't care that there e-mail is not working now because of
the forwarding.
If I were a big ISP, I would have strict SPF checking as an opt-in feature
for my customers for that reason. I have no way of knowing what
random aliases my millions of customers might have in place unless
they tell me.
Note that SPF checking can be RCPT TO specific and still reject forgeries
at SMTP time. In fact, I've come to the conclusion that even when you
don't have any RCPT TO specific SPF policies, it is better to delay
rejecting on SPF until RCPT TO - if only because logging who
the mail was for is important for debugging.
But.... again it comes back to the argument about forwarding. I know it isn't
SPF that is the problem, but the problem is there and is a major hindrance
*for* SPF.
Yes, but it is a problem with education for SPF checkers. The caution
senders have for publishing -all is misplaced. Instead, receivers
should be cautioned not to reject on SPF until they REALLY UNDERSTAND
what they are doing. They need to know and understand their forwarders,
including secondary MXs.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.