On Wed March 30 2005 09:32, Hector Santos wrote:
Look, when not just throw in IMAP in the picture. Its a RFC too.
It IS (appropriately) in draft figure 5.
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.
I see nothing that states a requirement. Indeed, although "must" appears
many times in the draft, it is unclear whether the draft (when published
as an RFC) would be Informational or Standards Track; if the latter, RFC
2119 should probably be specified as a normative reference with
appropriate use of MUST, SHOULD, etc. to clarify requirements,
recommendations, etc. If the draft is to become merely an Informational
RFC, it is meaningless to speak of requirements (though the hypothetical
Informational RFC might appropriately DOCUMENT requirements imposed by
Standards Track RFCs).
First, it is clearly not a generalized technology, but a specific
technology that is clearly not required.
From the (Standards Track) RFC 3028 Abstract:
It is meant to be extensible, simple,
and independent of access protocol, mail architecture, and operating
system.
Sounds "generalized" to me. And it is part of the Standards Track
Internet mail architecture (which, as noted in the quote above, does
not preclude its use in non-Internet mail architectures).
Second, it is a specific language that upon itself imposes specific
installation of specialized software.
It is, as RFC 3028's title states, a Mail Filtering Language. ANY
mail filtering language is necessarily a language and specific to
mail filtering. You have stated a tautology; so what?
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."
SpamAssassin is not an RFC. It is therefore not part of the standard
Internet mail architecture per se.
Forth, you certainly do not wish to minimize new ideas because of the
erroneous notion that it must be based on Sieve.
On the contrary, it is highly desirable to eliminate half-baked
cockamamie schemes which are harmful to the Internet mail architecture.
Any "erroneous notion" that a specific filtering method "must be based
on Sieve" is an error on the part of the parson making such an
assumption. On the other hand, given the fact of the "extensible,
simple, and independent of access protocol, mail architecture, and
operating system" standardized mail filtering language, any new method
that ignores Sieve is likely to be a niche method at best.
In fact, I don't believe
Sieve has yet to incorporate DNS based security functionality.
The beliefs of somebody who has apparently not read the first two
sentences of RFC 3028 section 2.7.4 are irrelevant.
Can it
implement SPF for example?
SPF is not an RFC. It is therefore not part of the standard Internet
mail architecture per se. It is fatally flawed w.r.t. that
architecture, as previously discussed here.
[...]
But we know for sure there are other "mail filtering" systems that do
offer DNS based lookup methods.
As specified in which Standards Track RFCs, specifically?
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.
Both DSN and MDN are based on the RFC 3462 (nee 1892) MIME
multipart/report media type. MIME itself is not a necessary part of
the Internet mail architecture or Internet Message Format; as noted in
the MIME RFCs, MIME is "largely orthogonal to" the Internet Message
Format. Moreover, DSNs depend on ESMTP (won't work with vanilla SMTP)
and a specific ESMTP extension. A case could certainly be made that
therefore neither DSN nor MDN are integral parts of the Internet mail
architecture because of their reliance on the separate MIME
specifications. In practice, however, I see nothing wrong with their
inclusion, as both are based on Standards Track mail-related RFCs.
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.
Nonsense. No compiler or "p-code" is required for Sieve. One
particular implementation may compile Sieve filters, but that is an
implementation issue, not a characteristic nor requirement of the Mail
Filtering Language.
It
requires a set of tertiary tools, such as MYSQL or some other requirement.
More nonsense.
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,
http://www.cyrusoft.com/sieve/.
So what? There is no requirement that any specific part of the
Internet mail architecture be implemented on a particular "operating"
"system" (or non-operating collection of cruft, as the case may be).
DSN and MDN do not require special "compilers" or "p-code!"
Neither does Sieve. DSN and MDN require MIME, though, and Sieve does not
(scripts that test MIME parts do, but that is not a requirement imposed
by Sieve per se). DNSs require a specific ESMTP extension, Sieve does
not.
[...]
DSN is based on a generalized bounce requirement that is a natural part of
the IEF. DSN is an optional and specific standard implementation of the
requirement.
MDN is based on a RFC 2822 header existence. Also a natural part of a IEF.
You are mistaken. Both DSN and MDN are based on MIME multipart/report.
DSNs are based on a specific ESMTP extension.
On the other hand:
Sieve is based on a Mail Filtering concept that is _not_ a requirement to be
part of the IEF process.
Filtering is not a requirement.
You can pull the "SIEVE" box, the message
filtering concept, out from figure 5 and you still have a generalized IEF
process that is widely in place. You can not do the same with Bounce (DSN)
or return receipt (MDN) concepts without breaking the framework.
Sure one can. Indeed, unless MIME (and in the case of DSN, DSN-specific
ESMTP extensions) is fully supported end-to-end, neither DSNs nor MDNs
are usable. Anything removed, however, results in failure to document
parts of the de jure Standards Track mail architecture. Just because
some part(s) of that architecture are unimplemented on some specific
platforms or on some parts of networks that are connected to the Internet
is not a justification for removal from the draft documenting the mail
architecture which is comprised of many Standards Track RFCs.
Suggestion:
- Change the Sieve box to MFA (Mail Filtering Agent).
While that might be a generalization worthy of due consideration,
barring specific references to existing Standards Track RFCs or drafts
which are likely to become Standards Track RFCs for other Internet
mail filtering methods, I see no reason to do so -- Sieve is THE
mail filtering language for the INTERNET mail architecture; it is
widely implemented, including by cross-platform MUAs (e.g. Mulberry).
One might quibble about some aspects of its inclusion in draft figure 5
(the gap in one of the lines, the fact that Sieve can be implemented
entirely in the rMUA or entirely in the MDA, etc.), but it is a widely
used Standards Track part of the architecture and should not be removed
from the draft.