[Top] [All Lists]

Re: pseudo LAST CALL - draft-crocker-email-arch-04.txt

2005-03-30 06:38:00

----- Original Message -----
From: <willemien(_at_)amidatrust(_dot_)com>
To: "ietf-smtp" <ietf-smtp(_at_)mail(_dot_)imc(_dot_)org>
Sent: Wednesday, March 30, 2005 4:55 AM
Subject: Re: pseudo LAST CALL - draft-crocker-email-arch-04.txt

No sorry I disagree i think this draft is not ready yet

A point about SIEVE

I think that sieve should stay in the draft becaurse of the Sieve
MIME extension (see RFC3028 section 7)  Sieve itself is on of the
many, many ways to filter spam, what makes it special is that it
is RFC and it has its own MIME extension. But I am open for
discussion on this point.  (this is also why i mentioned the
sieve message and not the sieve messagefiltering itself)

Look, when not just throw in IMAP in the picture.  Its a RFC too.

I am not asking for the removal of Sieve but to change the wording around to
point out very clearly it is not a requirement.  As it is worded, it makes
it seem to current or future newcomers that Sieve is a natural part of the
process, which it is clearly not.

First,  it is clearly not a generalized technology, but a specific
technology that is clearly not required.

Second, it is a specific language that upon itself imposes specific
installation of specialized software.

Third, there are a vast degree of different integrated frameworks that use
different "message filter" hooks.  Spam Assassin is probably the most
popular,  and there are many more mail filtering "hooks."

Forth, you certainly do not wish to minimize new ideas because of the
erroneous notion that it must be based on Sieve.  In fact, I don't believe
Sieve has yet to incorporate DNS based security functionality.  Can it
implement SPF for example?  Don't know myself, but I don't see it in RFC
3038. But we know for sure there are other "mail filtering" systems that do
offer DNS based lookup methods.

Finally, Dave brought up the question, what about DSN and MDN.

Same basic issues. It should be pointed out they are not requirements to be
part of the IEF.  But DSN and MDN are more well defined, very easy,
generalized structural issues that fit cleanly into the automated and
generalize framework.

Sieve, on the other hand, is a special and specific computer language that
requires a specific set of compilers and/or p-code interpreters, etc. It
requires a set of tertiary tools, such as MYSQL or some other requirement.
If you don't have all the requirements, you have to write it yourself.  In
fact, I believe there might be just one Windows implementation of it,

DSN and MDN do not require special "compilers" or "p-code!"

In my view, Sieve does not fit well in a "Generalized Internet Email
Framework (GIEF)."  Sure, mention it, no doubt, but don't make it sound like
its a "requirement" or a natural part of the GIEF.  It is not.

This document becomes nearly useless with such dependencies.

But then again, maybe that is what Dave wants the world to believe, that
Sieve is indeed a natural part of the Internet Email Framework - when in
fact, it is not.


Hector Santos, CTO
Santronics Software, Inc.
305-431-2846 Cell
305-248-3204 Office (Wildcat! Sender Authentication Protocol)  (WcSAP Anti-Spam Stats)

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