ietf-mxcomp
[Top] [All Lists]

Re: Where does MARID want to go today ?

2004-07-17 06:16:58
On Sat, 2004-07-17 at 14:14 +0200, Michel Bouissou wrote:
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.

I wholeheartedly agree with you here, and honestly i dont think anyone
has yet stated it in quite this way (except possibly Chuck Mead).

I believe you are correct in your line of thinking, and as an MTA
admin for a number of large mailing domains, that would be my "vote"
as well, to keep MARID out of the MUA business and stick to what is in
implementation now and WORKS.

I have see a few proposals from peers to the SES perspective that
helps the forwarding issue, but i dont see that currently on the table
in the MARID discussions. I personally would like to see the new-SES
proposals as part of the SPFv1-classic stuff, as i believe this adds
strength to the implementation.

MARID, i believe, should go down the road of SPF/SRS as that is the
current WORKING "implementation" and we have real data to prove that
this first step on the road map actually does do some what it was
intended to accomplish, is easy to implement, and doesnt add heavily
to any bandwidth issues that i am aware of. And i also believe alot of
the stuff people want to see in the MARID proposal/standard is nothing
more than feature-creep which i believe is what is holding SOME people
back from implementing even the first part of the road map - SPFv1.

Michael Weiner

Attachment: signature.asc
Description: This is a digitally signed message part

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