Mark -
The current MARID scheme, as described in the marid-core
and marid-protocol drafts, doesn't discuss a SMTP mail from
at all. MARID as a working group has been moving forward
on a scheme that checks the PRA, and adds the SUBMITTER
extension as a way to do that check before "swallowing the
message".
I appreciate the explanation and thank you for taking the
time to respond.
The difficulty with the presentation is that:
* Until the Submitter extension is widely implemented,
those relying 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
mailing list.
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
authentication stage.
Simply put:
* By not checking whether the SMTP mail from is properly
formed, and
* By not checking the SMTP mail from or EHELO address for
spoofing during the data transfer stage,
This creates a security hole, unless one says, we will
reject email without a Submitter extension.
Why? 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
required.
The argument has been put forward, yes but the gap is
filled with the use of reputation and accreditation
services.
The problem is that reputation and accreditation services
are not designed to thwart spoofing and the use of other
technical means to hide a spammers identity.
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 or her identity.
Until:
* there is sufficient implementation of Submitter in the
wild; or
* 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, I
suggest 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 identity.
Mark, I understand your role is to translate the
instructions you received from the MARID WG into a draft
protocol for Sender-ID.
My request was to ask you to review these instructions and
ascertain whether or not you could see your way clear to
dealing with a number of concerns.
I appreciate that you consider the instructions are clear
and that the only issue is does the MARID WG accept or
reject the PRA mechanism.
Again, thank you for taking the time to consider my
requests and provide a response.
John
P.S. In light of how the ultimate issue is now framed, from
my perspective this discussion has moved beyond being an
internal issue for the SPF discuss list, and it is
appropriate to raise the concerns noted above on the MARID
WG mailing list. Cheers, John
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.734 / Virus Database: 488 - Release Date: 04/08/2004