"Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org> wrote:
A DNS check that obtains a list of addresses for a
mailbox-domain,
MUST assume channel integrity when holding the apparent
originator
of the message accountable.
What channel? The only parties involved are:
a) SMTP client
b) SMTP server
c) DNS server being queried
I think he is refering to the channel referenced by
information theory (guessing by the previous reference to
Lampson's covert channel paper). This could refer to the
complete path through the communication system, or it could
refer to a single hop in a multihop system.
Further, you've oversimplified the parties involved:
The end user,
optionally a third party relay [one or more]
(because connection and mail services may be unbundled)
The mailbox provider (where responses will go)
The Mailbox provider nameservers
The recipient mail server [one or more]
The recipient nameservers
The chain of nameservers between the recipient, root,
and mailbox
provider.
At any point spoofing could occur.
This is true HOWEVER the only points at which this can be checked are
between the two current MTA's and DNS. How can my MTA possibly see what
the other MTA's are doing? buzzzzz
Going back to my spam examination where you are examining a
spam message: Suppose the IP address in the received from
header no longer matches the SPF records: In this case you
don't know if your SPF check passed because DNS records were
spoofed, or if the real DNS records were changed. All
you know is that you got a spam from a certain IP address.
You don't know
whether it was forged or not.
This is why the delay time is there. (28 days?) If it is no longer
there, then it *MUST* fail.
Suppose the IP address in the received header does match the
SPF records.
You don't know if the abuser signed up for an account with
that domain, or
if they got an infected machine under that domain. You don't
know whether
the nameserver was cracked, and incorrect records added. Most
people can't
tell the difference between a poisoned DNS cache and whether
the records
really come from an authoritative nameserver or even figure
out where they
got the DNS record from. So, similarly, all you really know
is that you
got a spam from a certain IP address.
Again, in this case it *MUST* fail
In both cases, all that can be done is report the incident to
the operator
of the domain and the operator of the IP address. And that's
all that can
be done now. THERE IS NO CHANGE.
SPF doesn't prevent email forgery, nor even indicate whether
forgery happened.
It is only being used to authenticate the IP of the the sending MTA.
The DNS server may return one, or a billion IP's
"permitted" to send
MAIL FROM with it's name. Any particular message may have
traversed
zero, or a billion intermediate SMTP hops before arriving at the
current SMTP client, and being sent to the SMTP server.
I fail to see how any party other than the three listed
above could
possibly be involved in "MAIL FROM" DNS checks. There is
no "channel"
beyond the current hop, which can be verified to exist.
The current hop cannot be "verified to exist" beyond the TCP sequence
numbers. There is no way to tell that the mail isn't forged. Even if
email comes from a certain server, there is still no way to
tell that the
mail isn't forged. <user>@aol.com coming from an AOL
mailserver doesn't
mean that it really came from <user> Spammers can get
accounts at AOL.
Spammers can steal accounts at AOL by a number of vectors
such as viruses.
This would be AOL's problem. And considering AOL's propensity to sue
spammers on it's network, I would love to see them try.
And what's more, from outside of AOL we can't be sure that
AOL isn't pink-contracting with spammers.
The notion of "spam-herding" is just so much wishful thinking.
"Spam-Herding" is my term and I believe that it will do exactly that. If
you are concerned about 'pink' contracts, then the spammers will be
herded to those. It will eventually become a matter of economics as
pressure is brought to bear on the otherwise legitimate IPS that may be
providing 'pink' contracts. Spam is not socially acceptable. It is
likely hated as much as paying taxes if not more. Social engineering
WILL take place with SPF fully deployed. The spam will be herded.
Regards,
Damon Sauer
"Putting my bee suit on"
*****
The information transmitted is intended only for the person or entity to which
it is addressed and may contain confidential, proprietary, and/or privileged
material. Any review, retransmission, dissemination or other use of, or taking
of any action in reliance upon, this information by persons or entities other
than the intended recipient is prohibited. If you received this in error,
please contact the sender and delete the material from all computers. 113