RE: Explain please (Was: SPF Stats)

David,

At 09:42 AM 7/6/2005, David Woodhouse wrote:
> On Wed, 2005-07-06 at 09:22 -0600, Commerco WebMaster wrote:
> > Okay.  Let's try working through the process to see if the issue can
> > be resolved.
> >
> > The receiving MTA at the ISP managing the virtually hosted domain
> > gets a message from a sender MTA where the original MAIL FROM: domain
> > holder has an SPF record protecting their domain.  Presumably the
> > receiving MTA also checks for same to discover that the original
> > outbound server from that MAIL FROM: domain is valid.  So far so good.
> >
> > That ISP MTA forwards its message onto another MTA, placing its own
> > stamp on the message header and connects to another or the final
> > target MTA, the intended recipient's MTA.  Now then, would not it be
> > prudent for the final recipient's MTA to look at where the message
> > came from?  In other words, wouldn't the recipient's MTA know the set
> > of MTAs that it would allow to send forwarded messages from their own
> > ISP by simply checking that ISPs SPF record at connection time?  Say
> > they forward through more than one forwarder.  Is it really that much
> > of a burden on the final recipient MTA to check the incoming
> > connection to make sure it is really an authorized forwarder to the
> > final recipient's MTA for even several forwarding MTAs?
>
> Yes. It's that much of a burden. The problem isn't really even tractable
> at the moment. You can't use the SPF record for the 'forwarding' domain;
> will list the _outgoing_ mail servers for the domain, rather than the IP
> addresses which its MX hosts may end up using for forwarded mail.
>
> That's even assuming that you can reliably force your users to list all
> such forwarding domains, which was a leap of faith in the first place.
See below.


> > And perhaps that should be true in all cases, but those where the
> > forwarders are known and trusted by the MTA receiving the forwarded
> > message.  After all, the receiver should logically be able to know
> > their allowed and trusted forwarders.  A sender cannot know the
> > recipients forwarders as it just sends to the MX it finds in DNS
> > (which for your example should be the ISP's MTA), but the final
> > recipient's MTA certainly should.
>
> No. Again you miss the point. The forwarding sites have nothing to do
> with _either_ the sending or receiving domains. The admin at my ISP has
> _no_ way of knowing how many of the thousands of forwarding services out
> there may be forwarding to his users.
>
> It just isn't practical in the general case for a receiving site to know
> the IP addresses of all the potential forwarding hosts.
I am not clear that I am missing the point at all.  If nobody knows 
the forwarding site, then how the heck did the forwarder get in the 
chain of email delivery in the first place?  Somebody must know the 
forwarding site or email simply won't get through.
When I send a message, my MTA must do a lookup to figure out the MX 
for the machine handling the domain to which the message is being 
sent.  That is the first machine in any possible forwarding chain or 
may well be the end point MTA machine handing the domain's 
messages.  That machine absolutely can do a reliable SPF check to 
determine if my MTA is valid for sending from my domain.
The domain to which I am sending a message to must have specified 
that MX (after all the domain owner does control their own DNS 
record), so they obviously know about that MTA.  End of story.
Now then, that MTA may be a forwarder to another MTA which could very 
well forward to 17 other disparately owned and operated MTAs outside 
their ISPs network, but the point is, right or wrong, it was the 
original domain owner chose to allow such a convoluted and 
unreasonable topology for their email services.  Not too many people 
are going to want to make such bad choices who actually want reliably 
delivered electronic mail service.  Even so, that domain owner will 
know exactly that path by which they can trust incoming mail because 
they established the parameters.  If that trust is broken, it happens 
by the very solution they (the receiving domain owners) set up, not 
by a problem created by an SPF publisher.
According to Spamhaus.org, there are some 200 individuals or groups 
who comprise the majority of bulk UCE.  For a moment, let's take them 
at their word.  Clearly, some portion of these may and others 
certainly do choose to use identity theft of domain names in email as 
a way they feel can cover their tracks.  So there are thousands of 
forwarders out there?  Fine, at least a couple of thousand might 
trace their owner / operators back to such individuals.  Responsible 
forwarders will know their networks and will succeed with SPF.
ISPs who chose to allow forwarding from other networks for their 
customers will either decide to support a list of such forwarders for 
their customers or take ownership of the process directly, hosting 
email services in their own network.  Incompetent or deliberately 
obfuscating forwarders will not (bad business controls) or choose not 
(spam friendly forwarding services) to know their networks.
You seem to indicate above that asking users to provide their 
forwarders is a leap of faith, but I think it is entirely reasonable 
if those users choose to establish such ways of having their messages 
transported and that it is not such a leap if those users actually do 
wish to continue to receive email service via their ISP.  The user 
has two choices, the ISP will cooperate in handling their forwarding 
service or they can use the ISP to handle their domain.  If the ISP 
won't handle email for them, they need to find an ISP who will put up 
with the complexities of incorporating forwarders into their networks.
If one makes a choice to "wash" their mail through a variety of 
forwarders belonging to disparate forwarding services, I'm here to 
tell you that one is making very a bad choice in a day where the 
ability to reliably confirm exactly from where the sender is coming, 
as regards at least the domain the sender claims, is getting very 
important to combat the growing problem of criminals committing fraud 
and malicious attackers who take advantage of the very holes these 
kinds of unchecked forwarding topologies allow to happen today.  That 
is just a reality of the changing complexion of the Internet and a 
need for reliable and trustworthy end to end email service.  This 
reality is driven by the need for business controls, not user whim.
Just because you can do something (e.g., forwarding through 21 
different networks) is the worst reason in the world for doing so.
The Darwin Principle applies here and SPF or any other anti-domain 
name theft in email solution is not going to be able to change 
that.  You cannot save everyone from their own bad judgement as 
regards their choices in forwarding strategies in an age where what 
worked once can no longer be trusted to work reliably in the current 
Internet environment, all you can do is to implement solutions that 
serve your own needs best.
In my case and that of so many other domain holders, for preventing 
domain name theft in email, that solution is SPF because it works.
> --
> dwmw2
David, as you have now entirely exhausted my willingness to further 
repeat that SPF works for me any my company with all the other 
businesses and individuals with whom email communication occurs from 
here, I thank you for the opportunity to have this exchange and bid 
you well in your efforts to implement whatever works well for you.
Best,

Alan Maitland
WebMaster(_at_)Commerco(_dot_)Net
The Commerce Company - Making Commerce Simple(sm)
http://WWW.Commerco.Com/