--Hector Santos <winserver(_dot_)support(_at_)winserver(_dot_)com> wrote:
In each case, SPF would by pass the spoofing of the winserver.com domain.
That is not a badly configured server, but one that is maliciously
spoofing the helo domain by using our local domain, winserver.com
Hector- Thanks for the explanation. I believe a number of other people on
this list have addressed your concerns more effectively than I could. The
most I could really do is to repeat the statement already made multiple
times: checking HELO is not the design goal of SPF.
I have said repeatedly, that SPF should only check for HELO/EHLO local
domain spoofing. Checking for external domain spoofing should be a system
implementation option.
I understand that this is important to you, but I don't understand the
emphasis on "local domain spoofing" vs. "remote domain spoofing". Anyway,
if it is only used for local purposes, there are a number of tools you
could use that are more effective than SPF.
MUA ---> MTA1 ---> MTA2 --> MTA3 ---> Final Destination.
In other words, for transactions MUA-MTA1 and MTA1-MTA2, there is no need
for "validation" because the session is already trusted/authenticated.
SPF is breaks down with the MTA2-MTA3 transaction unless MTA2 is allowed
to send mail on behalf the MTA1 domain network. SRS attempts to address
this. Reading the Received: lines can also be used.
But regardless, if you want to use SPF at MTA3 and attempt to create an
"enforcement policy" for MTA1, then you must also require MTA2 to use a
valid FQDN HELO domain.
In other words, you can't have it both ways.
- MTA1 must comply with the MAIL FROM:
- However, MTA2 doesn't have to comply?
Something wrong with that picture. If MTA2 is a spoofer, then the odds
are really high that MTA1 is a spoofer too.
SPF only works if the "links" in the chain are consistent.
Sorry, I totally did not understand this section. You seem to be making a
point that since there are multiple MTA's that handle the message, this is
somehow a hole in SPF. SPF only concerns itself with where the messages
leave your network on the way to mine. I assume the system administrator
has better ways of checking the local machines for spoofing.
In other words, SPF was designed to check mail from "remote" machines so
that the "ip" matches the policy for "mail from" domain. Trying to use it
to check mail from "local" machines so that the "helo" matches the policy
for "local server names" is in my opinion, using the wrong tool for the job.
By far, most people will be more concern "first" with protecting their
system and the malicious and criminal fraudulent usage of your domains and
address. So local domain spoof protection is the #1 benefit all the LMAP
proposals offer and this will work 100% all the time.
I agree with the first sentence, but the second sentence doesn't logically
follow. Malicious/fraudulent use of my domain can happen anywhere on the
internet. If it happens on a local system I have much greater control. I
am much more concerned when it happens on a remote system.
I have not stated whether an SPF record has to be used for helo domains.
What I am saying is the "functional specification" needs to have it
written in stone that local domain spoof checking is a requirement
otherwise the SPF benefits are lost..
I don't agree with this at all.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>