ietf-mxcomp
[Top] [All Lists]

Re: What Meng said

2004-08-13 08:30:14
Meng and MARID Community,

On Aug 13, 2004, at 01:56, Meng Weng Wong wrote:
Therefore, immediately rejecting after MAIL if (the
SUBMITTER value is not provided and r2 is FAIL), is no worse
than continuing to accept the message and extracting the
PRA, because the PRA can be expected to fail anyway if it's
forwarding.

This means that we *can* safely assume,
in the absence of SUBMITTER, that MAIL-FROM == PRA,
whether or not we think the sender is omitting it because
1) they are not Sender-ID aware, or
2) they are aware and Mail-From == PRA.

If we do this, then the essential requirements of the SPF
Classic community are respected in Sender ID.

I do not think this course of action harms the essential
requirements of Caller ID so why not make both sides happy?


As a new participant who attened the MARID F2F, I would like to suggest that Meng's interpretation should be cast in the Sender-ID specification. It currently is not. Judging by Mr. Lyon's (jimbo, jimlyon(_at_)exchange(_dot_)microsoft(_dot_)com) comments, he has a very different interpretation and expects Meng's Mail-From checking to occur some time in the vague future, if at all. This does not sound like the parties to the merging of the SPF and Caller-ID specs have the same interpretation. Because premature marketing activities are being introduced today before the Sender-ID spec is finalized nor the IPR issues determined, there is a very real chance that marketing may overwhelm the standards process. We should tread carefully here. The rush to specification for Sender-ID seems ill advised.

The SPF community has some operational experience with the effectiveness of Mail-From checking. (I volunteered to work with the SMTP-Verify group in ASRG to document this experience. Please join me and help perform this important test of engineering assertions.) Furthermore, because Mail-From checking is conceptually simple, it offers implementation simplicity and a good method to harden the mapping between domain names and IP addresses for email. It is not the only solution. At the MARID meeting, I encouraged this community that if they were willing to extend SMTP with SUBMITTER then they should, at the same time, consider tightening up HELO/EHLO checking. From this list, Meng has also proposed that we eliminate sending to non-MX advertised hosts. Both of these issues should be considered before embracing the addition of new tags. Perhaps an ESMTP extension, say STRICT, could be used to announce both support of and adherence to HELO/EHLO checking and only sending to MX advertised hosts. (As I am, obviously, not an SMTP expert, I encourage others to make a real proposal.) I am just identifying that these loose interpretations of the SMTP spec have contributed to the abuse of the email system. Shouldn't we try to close those holes and exploit DNS as an important "third party" identifier/authenticator service to improve email?

I am saying that simple mechanisms without IPR encumbrances should be exploited by this community. SPF-Classic and some form of stricter SMTP checking meet this criterion. The PRA and other mechanisms may offer value but, because of their complexity, should be deferred until these simpler mechanism's specifications are finalized. As the difference between Mr. Wong's and Mr. Lyon's interpretation of the Sender-ID spec shows, there is still some important conceptual work to be done here. A rush to deploy a complex implementation that may not have the desired anti-spam/anti-phishing effect is not good engineering practice. In other words, while we have an extremely rough consensus, the running code may not actually solve the identification problem. We should look to simplify and refine our solution.

Andrew

____________________________________
Andrew W. Donoho
awd(_at_)DDG(_dot_)com, PGP Key ID: 0x81D0F250
+1 (512) 453-6652 (o), +1 (512) 750-7596 (m)


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