Thanks for your reply it made me think again about message filtering in general
and sieve in particular.
I hope that I am not seen as a promotor of Sieve and that in my responce I made
clear that I was not talking about Sieve as mailfiltering service but as a
special kind of e-mail message. (an email message that goes from the MUA >>TO<<
the MDA instead of the other normal way)
I am aware that the distinction is easy made especially because in the current
draft messages and services are put in one section. That is one of the reasons
why I wanted to split the services section in two seperate sections one for
messages and one for services setting. The other was to create sub sections
for message technicalities and the different messages.
A general remark in the services section about mailfiltering services like the
one you suggested is fine with me, but I would suggest:
section ? Services
?.1 Message Filters:
Spam and virusses are becomming a bigger and bigger tread to the safety and
usability of the internet mail system.
Message Filters provides a means of specifying conditions for differential
handling of mail,
Most common is to do that in the MDA or MUA, but filtering can be done at many
different points along the transit path.
Sieve [RFC3028] is one such implementation but there are many other Message
Filtering dialect directives, especially within a single AU.
BTW I always thought of Sieve more as a scripting-language that would use the
spam and virusscores of REAL mail filtering programs.
From the sieve homepage http://www.cyrusoft.com/sieve/
Sieve is intended as a first-stage building block for mail filters, although
one that in and of itself provides significant functionality for a large number
of possible uses.
Sieve scripts are simply data for Sieve engines to execute.
Sieve is not a once-and-for-all solution for pressing problems addressed by
filtering, such as anti-Spam efforts, although it certainly is intended to
facilitate construction of such solutions.
I hope You and Dave (and everybody else) can live with this sugestion, but
please respond if you do not agree with this
IMAP is in the draft
SFP is not (it is no RFC yet that is maybe why on
http://www.imc.org/ietf-mta-filters/mail-archive/maillist.html there are no
post on SFP , or maybe I just did not searh long enough)
----- Original Message -----
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
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.
http://www.winserver.com/wcsap (Wildcat! Sender Authentication Protocol)
http://www.winserver.com/spamstats (WcSAP Anti-Spam Stats)