From: Mark Lentczner
Sent: Monday, July 05, 2004 5:24 PM
Along these lines, I'm looking for a reasonable example that motivates
such a situation. The above example is too contrived: Really if you
trust all of 192.168.0.0/16 to use your domain name in MAIL-FROM, then
surely you trust any such host to use it in HELO. Guarding against
your own errors in configuring your own machines isn't good enough for
my purposes.
Unknown modifiers are ignored, so with care, we can avoid breaking any
existing parsers. If they don't ignore unknown modifiers, they are broken
and they need to be patched. We still have few enough implementations that
we can slide in some changes. Despite the fact that there are a lot of
domains publishing, relatively few are actually checking SPF, so we don't
have to lock ourselves in just yet.
As a real-world example of the disconnect between the different names, my
mail has a return-path domain of GoodmanAssociates.com, but my provider
(Interland) has their MTA farm under the domain RegisteredSite.com, so I
expect that is what they HELO as. For this setup, _no one_ should ever HELO
with GoodmanAssociates.com, and any mail purporting to be from me better not
have RegisteredSite.com in the return-path.
I didn't cook up Unified SPF, but since it's on the table, we better figure
out a way to gracefully handle it. We've already got way too many DNS
queries to resolve the average SPF record (I've heard the number of 6-7
queries per SPF record as being typical). This is getting to the point
where it is almost as expensive as an SMTP callback, which many rejected as
having too much overhead. Adding another level of recursion is not a good
idea.
--
Seth Goodman