Meng 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?
I have two concerns:
* Technical -
Meng, if we are going to say:
MAIL FROM = SUBMITTER
Therefore in the absence of SUBMITTER do checks on MAIL FROM
Why not:
* require malformed SMTP mail from checks as a pre-cursor
to avoid spammers from sending IP to recipient MX as was
the case in the first US Bank phish?
* allow for EHELO/HELO and PTR checks as well?
I realize my questions are a bit awkward especially given
Andy's previous comments, but if we are going to appease
the classic SPF community to solve a problem, why not also
appease the unified SPF community?
Also, how is the classic SPF or unified SPF community
appeased if MS has yet to commit on the license format?
(On this point, I acknowledge it was agreed the WG was
going to do the engineering work first and then deal with
the license issue, depending on the MS proposal, but ...)
In other words, from an engineering/design perspective,
either:
* the Sender-ID design is amended to fully meet the 'social
concern' and the 'redundancy design concerns;' and,
* MS fully commits on the license issue to meet the
concerns of the open source community; or,
* don't meet them at all and allow the design to stand as
it is, acknowledge that MS is going to file a defensive IPR
claim, while requiring a royalty free license in the format
it feels appropriate, then everyone can clearly understand
exactly what this means and the WG can make an informed
decision.
(I suspect my comments are a bit pre-mature and if they
are, I apologize.)
My own view is that:
* the design should be amended to fully meet the social and
redundancy design concerns.
* MS should commit to meet the concerns of the open source
community, while protecting its own interests.
Meng, I appreciate your position is a compromise.
I both respect and applaud your effort. Hopefully something
is worked out which keeps the open source and corporate
communities in the same tent.
If what you propose works, great ...
* Implementation/Non technical -
This question is for Harry,
Sender-ID is going to require some 're-jigging' of message
headers.
The US Federal Government, Australia and the European Union
all have written laws regulating commercial email.
All these laws tell people in essence not to use 'deceptive
headers.'
The US Federal Law in particular has some very specific
prohibitions, especially as to what can and cannot go in
the from line, etc.
Both Australia and the US are in the middle of their
process to write specific regulations.
In the EU, most nation states have transposed the EU guide.
Sender-ID is creating a new identity which did not exist
when the Australian, US and EU laws were written.
I have particular concerns, especially given some proposed
suggestions I have seen involving how ESPs should proceed
and whether these are or are not off side with the US
Federal law.
Has anybody bothered to check to make sure we are not
creating the ultimate catch-22?
Yes, you can authenticate your identity as a sender, but by
complying with the Sender-ID protocol, you put yourself off
side with local law. Woops.
Harry, could you raise this with the lawyers at MS? I
appreciate this may be a 'ghost' concern, but ...
Implementation - PR
On the PR side, yes, it is disconcerting and in some cases
amusing to read a series of PR releases concerning
Sender-ID published yesterday and today in the online media
in which folks are making all kinds of statements,
including one ESP saying "we are Sender-ID compliant," when
the draft protocol is not finished and nobody is using
Sender-ID in the wild.
But ... I am not sure there is much this group can do,
unless the WG chairs decide to issue a press release. Given
the last brouhaha which occurred after one of the chairs
was interviewed ... somehow I suspect silence is the rule
of thumb.
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