Dave,
My only problem with the draft in your attempt to make it a standard is the
how you insist in imposing "Sieve" a specific technology and clearly a
specific language framework in what is otherwise a generalize Internet Email
Framework.
I brought this up atleast twice already over the year and I don't see why
you refuse to make the "Mail Filtering" element of your framework more
generalized. Everything else in the document is generalized. You didn't
mention specific MSA, MTA software for obvious reasons. SIEVE is a
specific MAIL FILTERING language. Sure, reference to it. But please don't
impose it as the required MAIL FILTERING element in your framework.
Why is it an issue with me?
We don't use SIEVE and we don't intend nor plan to use SIEVE anytime in the
future. We have our own "Mail Filtering" component, just like we have our
own MSA, MTA, etc. We spent an awful lot of time and energy making sure
our software is compliant with the standard. We provide confident to our
customers based on these standard operational assurances. The last thing we
want is to be getting into is silly debate games such as "Based on the
standard Internet Email Framework (IEF), since you don't use SIEVE, you are
not compliant with the IEF standard."
Suggested small changes:
| 4.1 Message
|
| Message Filtering:
|
| Message Filtering provides a means of specifying
| implemention specific conditions for differential handling of mail,
| at the time of delivery. One such implementation is SIEVE [RFC3028].
Figure 5
| shows a Message Filter operation going from the rMUA to the MDA. However
| filtering can be done at many different points along the transit path and
| any one or more of them might be subject to Message Filtering dialect
| directives, especially within a single AU. Hence, the Figure shows
| only one relationship, for simplicity.
The small changes wouldn't be much to ask right? These small wording
changes will remove all PR pressures on vendors who don't use sieve or don't
wish to use it.
This small consideration will be appreciated. As far as I'm concern, the
lack of the consideration completely undermines (make it useless) in what is
otherwise a fine document.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office
http://www.winserver.com/wcsap (Wildcat! Sender Authentication Protocol)
http://www.winserver.com/spamstats (WcSAP Anti-Spam Stats)
----- Original Message -----
From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
To: "ietf-smtp" <ietf-smtp(_at_)mail(_dot_)imc(_dot_)org>
Sent: Tuesday, March 29, 2005 11:23 AM
Subject: pseudo LAST CALL - draft-crocker-email-arch-04.txt
Folks,
I've submitted draft-crocker-email-arch-04.txt as the latest revision to
the
Internet Mail Architecture document.
Since the changes are relatively small, I'm going to ask folks to treat
this
as a Last Call on the document.
In a couple of weeks, I'll ask the IESG to consider the document for
Proposed
Standard.
Please consider doing a review on the document, with that goal in mind.
Until the draft is issued through the Internet Drafts process, it can be
accessed at:
<http://bbiw.net/current.html#email>
Thanks.
d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net