ietf-mxcomp
[Top] [All Lists]

RE: What Meng said

2004-08-17 12:20:24

From: Meng Weng Wong Sent: August 17, 2004 10:26 AM

On Mon, Aug 16, 2004 at 11:26:39AM +0100, Chris Haynes
wrote:

Please may I ask a brutally simple question.

My question below applies only to those messages in which
the domain of the MAIL-FROM is different from the domain of
the PRA.  Where, in the collection of drafts issued on
Friday, does Sender-ID refer to the rejection of a message
as a result of evaluating the record associated with its
MAIL->>FROM domain?"

Sender ID as currently specified doesn't do that.

If people want the MAIL FROM to play a role in Sender ID,
they should say so.  If they do not say so, the working
assumption is that nobody cares.

I personally think that if the PRA lookup returns "none" or
"unknown", MAIL FROM should be checked, and if that test returns
"fail" then the message should be rejected.

This is in line with the "unified SPF" model.

The converse is the scenario where a MAIL FROM pass is returned,
and a receiver arrives at a generally positive feeling about the
sender; that would allow EzMLM and similar MLMs to get their
mail through, and reduce the false positives that would occur on
a PRA check alone.

My comments:

* At present according to its site and related information filed
with the IETF, MS is claiming an IPR in Sender-ID, proposes to
file a defensive patent and is requesting software developers to
sign a royalty free license.

* We will not know whether MS will accommodate its required
license to meet any expressed concerns of the open source
community until August 23.

* Based on this, the only workable presumption, given
previous comments made to this list concerning the
licensing issue, is that some open source mail software
will not be able to accept the license and therefore will
not be able to alter their software to be compatible with
Sender-ID, as the protocol is presently on the table.

The change that Meng is saying he would like to see in the
protocol documents, which others have requested, brings with it a
number of benefits:

* It removes an apparent design flaw in Sender-ID by reducing the
risk of false positives.

This would seem to be a fundamental argument in support of Meng's
position, given the mandate of this WG.

As to the argument about mail forwarding, Meng has used the word
"should" not "must" in his proposal.

* It allows software developers within the open source community
to design plug-ins for mailing software that support Sender-ID
without having to adopt or support the PRA algorithm, simply
relying on the SMTP mail from check and by adopting the plug ins
available to support mail forwarding.

This means the license request by MS becomes a non-issue, except
for those in the open source community who wish to implement
Submitter and support PRA at the data transmission stage.

I simply point this out so that as requested by Harry Katz,
MS can take this matter into consideration as it works on
its final IPR/license proposal.

* It means that senders are not compelled to publish an SPF
record and a Sender-ID record.

Nice, but not fundamental.

* Most importantly, it strengthens the protocol from the
receiver's perspective, particularly large mail box providers and
large corporate network providers who are facing the greatest
crush and cost in the ongoing war against spammers.

Why? It means large mail providers can require PRA and SMTP mail
from checks using Sender-ID and EHELO/HELO checks using CSV.

This strengthens the receiver's hand, while further
reducing the risk of false positives.

What happens if this change is not made?

SPF is not before this WG as a formal protocol.

The approach put forward by Meng overcomes the problem
which many organizations will face if Sender-ID does not include
a formal SMTP mail from check in the absence of PRA at the data
stage.

Should they or should they not adopt and use a protocol,
namely SPF which allows for an SMTP mail from check, so reducing
the risk of false positives, but that has not been formally
approved by the IETF.

Without the requested change, organizations are put in a
box.

We want to follow the rules. However, by following the
rules we adopt a protocol which according to one of the designers
may result in an increased false positive rate. This is not in
our interest.

We can avoid the problem by implementing SPF and Sender-ID,
but then we are not following the rules and this puts us
into never, never land.

* Design Perspective. The underlying reason for having
syntax strings for each design is this allows each protocol
to focus on one issue. In the case of Sender-ID this is
PRA.

By writing a design for Sender-ID which focuses on PRA and
includes SMTP mail from this is a change in design perspective.

The question becomes, does this change bring with it any
negatives?

Given PRA is a new model version of SMTP Mail From (Both
SPF and Sender-ID break mail forwarding) I don't see any.

Having said this, I am not a design, security or
operational expert and there may be one or more actual
reasons which require consideration.

* Delay. By accommodating this request, will it further
delay the process of getting Sender-ID out of the box?

The design work has been done on running an SMTP mail from check.
Draft protocols are readily available. Open source plug ins are
available both for mail from and re-sent mail from. There is a
very lively community available to provide support.

* The merger of SPF with Caller-ID. Some are critical of
this.

What I do know is:

* We are where we are; and

* We have an opportunity to make the present proposal
better, without any downside.

As Margaret pointed out:

"and more net happiness in the world is also a good thing
:-).

For all these reasons, I support Meng's request.

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.737 / Virus Database: 491 - Release Date: 11/08/2004
 



<Prev in Thread] Current Thread [Next in Thread>