Le samedi 17 Juillet 2004 10:42, Hector Santos a écrit :
I wish to clarify that my critical concern is that the "MARID"
solution is being molded that is not ideal for world wide consideration
[...]
I share this opinion.
I've been reviewing MARID drafts and discussions, and came to the conclusion
that the current direction it takes makes little sense IMHO.
If we want the protocols/standards defined by MARID to be successful and
useful, they must be widely and quickly acceptable by the whole Internet
community, prove efficient, and be easy to implement and use on a purely
technical standpoint.
email forgery is a hot issue that needs to be addressed with protocols that
mail administrators will be able, and willing to implement and deploy in a
relatively short timeframe, and not 3 years from now (if ever).
IMHO, all the 2822 and PRA stuff doesn't fit with this goal.
The 2822/PRA algorithm is rather complex and will probably raise
implementation issues in many MTAs that currently don't have much provisions
for message contents processing, and possible message rejection _after_
message DATA have been received and processed.
OTOH, 2821 processing such as SPF is easier to implement, all MTAs being
designed for acting upon message envelope contents. There are already a
number of MTA implementations of 2821/SPF, either by the means of MTA patches
asociated with an SPF library, or by external "plugin" modules. All this
already exists and has real-world implementations that prove satisfactory.
Such implementations could be easily extended to include more 2821 tests that
MARID could define, such as HELO validation.
I believe that the present email RFCs have very wisely separated transmission
protocol and message envelopes (RFC2821) from actual message contents
(RFC2822), the former being the actual MTA business, and the later, message
contents, being rather MDA / MUA / user application layer business.
I believe that trying to incorporate a bunch of 2822 processing into MTAs for
implementing PRA would _not_ be a good direction to take, as this basically
is not MTA's business.
Also, if we consider efficiency / bandwidth issues, it is much better to
reject a message before its DATA has been received (by 2821 processing),
rather than having to receive the entire message, perform 2822 PRA
processing, then possibly reject it (or worse, bounce it back).
If we now consider the issues of the "side effects" of these protocols, we
know what 2821/SPF breaks : it breaks forwarding, but this can be solved by
the already-designed SRS solution, which already has some implementations
beginning to become available, or that will be shortly. And this is MTA-level
implementation and business, it doesn't need any further changes to
application or user-level software .
If we consider 2822/PRA, we notice that it relies on supplementary message
headers (i.e. Resent-From:, Sender: ), that most email systems currently do
not add when performing simple alias or ".forward" forwarding, or user-level
forwarding, and that a number of mailing-lists systems (for example, SYMPA
[http://www.sympa.org], which I happen to use) do not currently add nor
manage.
2822/PRA draft even discusses modification to M.U.A. software for displaying
fields that are used for PRA computations.
Well, folks, I believe that such adaptation of all forwarding systems,
mailing-list software, MDAs and the like will not be widely deployed in the
"real world" before years, if ever.
Furthermore, I think that a wide deployment of 2822/PRA would uncover a number
of yet unforeseen issues, and that all this seriously lacks large-scale
testing for now.
SPF already has received a very strong support from the real-world sysadmins
community : http://spftools.infinitepenguins.net/register.php already knows
more than 21,300 domains that actually have published SPF records (and
counting), and some people estimate that the actual figure would rather be
around 100,000 (even though I don't know on which basis this estimation
relies).
This is a massive vote for the SPF technology, and shows that a massive number
of real-world sysadmins estimate that this SPF technology is both useful and
easy enough implementing, without breaking too much of their existing mail
setup.
On the other hand, about 2822/PRA, we only have a big question mark.
Taking all of these points into consideration, I believe that MARID should
seriously reconsider the direction to be taken.
My own preference would be that MARID defines as a standard (in a first time)
the current implementation of SPF, with some possible improvements such as
HELO verification, but remaining strictly 2821. And accompany this with the
standardization of SRS, that solves the forwarding issues.
That would give a "2821 MARID RFC" that could be rather quickly deployed in
the real world and show its benefits against mail forgery.
As a second step, later on, we could consider if "what remains of email
forgery once SPF is widely deployed" deserves that an additional 2822
standard should be devised, or not.
If it happens that pure 2821/SPF is able to block 98% of email forgeries,
zombie spam and virus problems, then I think that MARID would have
brilliantly reached its goals, and no further protocol is necessary.
If it shows that, alas, 2821/SPF is not sufficient to solve enough of the
problem, then it will be necessary to consider another 2822-based protocol.
But I think that anyway, the priority for now is validating a 2821 protocol,
and, maybe in the future, if a 2822 protocol shows necessary, it should be
kept separate from the 2821, just as RFC2821 and RFC2822 are separate.
These were just my 2 cents...
Regards.
--
Michel Bouissou <michel(_at_)bouissou(_dot_)net> OpenPGP ID 0xDDE8AC6E