I have a couple of concerns and perhaps people can clarify
Based on my understanding of what transpired at last week's
MARID WG meeting one of the issues surrounding Sender-ID is
the implementation of Submitter in the 'wild.'
My concern is whether in how we are approaching the problem
we are creating a potential security issue for ourselves.
Let me explain.
My premise is that the spammer's objective is to find a
security hole, be it at the authentication stage, (which
may also include reputation and accreditation checks), or
at the filtering stage and to exploit these gaps to allow
for message delivery, while hiding his, her or its identity.
This raises a number of problems:
* Until the Submitter extension is widely implemented,
those relying solely on PRA checks will have nothing to
check, unless one allows for checking SMTP mail from in the
absence of the Submitter extension.
* Sending direct from the IP address to the recipient MX is
the way a lot of spoofed and phishing messages are sent.
This happened with the US Bank phish coming from a Chinese
IP address, which was discussed at length on the MARID
Until the Submitter extension is widely implemented, those
relying solely on PRA checks, would not have verified
whether the SMTP mail from is malformed and so would have
failed to reject this type of message during the
(This is a short list. I know there are many more issues.)
As a result:
* By not checking whether the SMTP mail from is properly
* By not checking the SMTP mail from and/or EHELO address
for spoofing during the data transfer stage,
Does this create a security problem, unless one says, we
will reject email without a Submitter extension.
Why? I go back to my original premise. A spammer who sends
spoofed email or wants to go phishing has no interest in
complying with the rules we write.
Rather, he or she is seeking to utilize any 'security
holes' we allow for message delivery.
The problem? We can't say we will reject email without a
Submitter extension because an implementation time frame is
The argument has been put forward, yes but the gap is
filled with the use of reputation and accreditation
The concern is that reputation and accreditation services
are not designed to thwart spoofing and the use of other
technical means to hide a spammers identity, but rather to
deal with whether the sender does or does not have a good
A reputation service says in essence, this sender whom we
can identify, based on past mailing practices has a good
An accreditation service says in essence, based on our
review of this sender's actual or proposed practices, we
are satisfied this sender either: (i) has honourable
intentions, if it is a market newcomer; or (ii) has a good
history and in either case we are prepared to vouch for
this sender whom you can identify.
Oh and by the way, should it turn out this sender does not
live up to his, her or its commitments, and we find out,
either through our own means, or based on relationships we
have, we will 'tar and feather the person':-)
Without the ability to specifically identify the sender,
are we not into blacklisting and filtering, along with the
related collateral damage, which is a concern for the
sending community and makes email unreliable for users.
As such until:
* there is sufficient implementation of Submitter in the
* the receiving community says, want to send us email, you
must use the Submitter extension,
without calling for the use of a malformed SMTP mail from
check, a spoofed SMTP mail from and an EHELO check, my
concern is we have not moved towards the underlying
objective of sender authentication which is to thwart
spoofing and the use of other technical means to hide
The other concern involves the less developed parts of the
world, and the use of the Internet infrastructure in these
communities by spammers to play havoc.
Do we know whether these communities can bear the cost if
any of Submitter implementation?
If we can rely on accreditation and reputation services to
fill the gap, do we know whether 'legitimate' senders in
under developed countries can realistically bear the cost
of accessing accreditation services?
Do we have any idea of a realistic time frame to allow for
sufficient implementation of Submitter in these parts, so
that receivers can fairly say, "we will require all email
sent to us to have a Submitter extension by such and such a
I am not saying based on all these concerns this means we
should reject Sender-ID.
(In my view, crunch time will likely occur when MS comes
forward with any IPR disclosure and the form of license, if
any it may require and how this pans out.)
What I am saying is either:
* Allow for a draft of marid - core to come forward which
takes these concerns into consideration; or,
* If it is felt the better course is to keep the marid
drafts pure, which is understandable, then we need to
quickly move ahead with review and implementation of
proposals like CSV and any others which directly confront
This will allow the receiving community if it wishes to
receive a full stream of data sets and achieve the
underlying objective of sender authentication, being to
thwart spoofing and the use of other technical means to
hide identity, while allowing prudent senders to clearly
know and comply with the agreed rules.
The FTC Calls For Sender Authentication
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.734 / Virus Database: 488 - Release Date: 04/08/2004