I am having some difficulty with the analysis of this
situation.
Let me explain.
The header which I provided earlier to the list indicates
to me a malformed "SMTP mail from address," with the SMTP
mail from address being null.
(As an aside, the server logs found on the messagelevel.com
web site in the review of this message confirms how I read
the message header.)
What does this mean? It means the sender is directly
accessing the receiving server through his or her computer.
I am writing this in non technical terms for a reason.
The much aligned US federal law regulating commercial email
tells us:
"Whoever, in or affecting interstate or foreign commerce,
knowingly--
(3) materially falsifies header information in multiple
commercial electronic mail messages and intentionally
initiates the transmission of such messages"
is committing a federal crime.
(see section 4 of the CAN SPAM Act of 2003. You can find a
copy of the Act at
http://www.learnsteps4profit.com/antispamus.html)
In this same section, materially is defined as follows:
"...header information or registration information is
materially falsified if it is altered or concealed in a
manner that would impair the ability of a recipient of the
message, an Internet access service processing the message
on behalf of a recipient, a person alleging a violation of
this section, or a law enforcement agency to identify,
locate, or respond to a person who initiated the electronic
mail message or to investigate the alleged violation."
It is a material falsification to spew a message into the
system with "malformed" information "that would impair"
one's ability to "identify, locate, or respond to the
person who initiated the electronic mail message."
So what you may ask? Any protocol for sender authentication
has to instruct the receiving mail server to check for
malformed "mail envelope" information and if found, reject
the message at the transport stage.
Why? This serves the basic purpose of helping to confound
the spammer's ability to spoof messages, which is the FTC's
basic premise for supporting sender authentication.
(See page 12 of the FTC's report on the feasibility of a
National Do Not Email Registry.
http://www.learnsteps4profit.com/dne.html)
Now the question becomes does the SPF or Sender-ID protocol
help to achieve this goal?
Using the original SPF algorithm, the receiving MTA first
checks the SMTP mail from address for a domain name.
If there is none, the instruction was to retrieve the
domain from the helo line.
Upon retrieving the domain from the helo line, the
receiving MTA would then check for the domain's SPF record.
Since usbank.com has not published a sender policy
framework record, the answer would be none and therefore
under the original protocol the receiving MTA was to allow
the message to pass.
I am relying on the following draft: -
http://spf.pobox.com/spf-draft-200406.txt
This analysis exposes a potential error in the original SPF
algorithm. Let me explain.
The instruction should have been:
* First check the SMTP mail from address for a domain.
* If there is no domain to check, this means the message
mail envelope is malformed. The receiving MTA must reject
the message.
The only question I have is, "when the receiving MTA
rejects, does it send a note to the helo address (being the
return path) explaining the reason for the rejection?"
Under the SPF marid protocol document, which ties in with
the Sender-ID marid core document, I suggest this issue is
resolved.
Since there is no domain in the SMTP mail from address, the
mail envelope is not formed properly. The instruction is to
reject the message.
(I presume this is the intention of section 3.3 titled
initial processing as found in
http://spf.pobox.com/draft-ietf-marid-protocol-00.txt.)
If this is not the case, then I suggest the authors of the
SPF marid protocol document can easily change the initial
processing instruction to rectify this problem.
Why? Sending direct from the server, using port 25 to
bypass accessing an SMTP mail server and connecting
directly to the receiving mail server is a classic spamming
technique used to hide ones identity.
I suggest sender authentication should and can easily
defeat this technique which is used time and again to spew
messages into the system and hide identity.
Of course, I acknowledge there could be a flaw in any of my
premises or understanding of the respective protocols.
If there is, please correct me.
John Glube
Toronto, Canada
The FTC Calls For Sender Authentication
http://www.learnsteps4profit.com/dne.html
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.725 / Virus Database: 480 - Release Date: 19/07/2004