ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
First of all, I personally could not care less if the architecture document
has the word "sieve" in its diagrams or not.
Having said that...
On the other hand, how often do you see example procmail recipes posted to
accomplish some given end, and how often do you see people post SIEVE scripts
to do something?
In my neck of the woods it's well over 10 to 1 - in favor of Sieve.
Thats the point, other people will have the different exposure.
But even then, if you follow this premise, why not just SENDMAIL for the
MTA componetns, or BIND for the DNS components, etc.
SIEVE is a "specific product" it is not the language used across the
board when it comes to "Mail Filtering."
In addition, where mail filtering is applied differs for many systems.
For example, one of our MFA bots is activated at what Dave calls oMSA I
believe. It is done before acceptance which is a major break from what
that diagrams exhibits if I understand it right and more and more
systems are doing the same thing to provide NON-BOUNCE rejection sessions.
What about SpamAssassin filters, and Sendmail Milters that
do filtering?
Now you're comparing apples and oranges and pears. Sieve is not intended to be
a platform for writing general purpose anti-spam and anti-virus filters and
anyone who attempts to do so in Sieve is a fool. Rather, Sieve provides a means
for users to implement simple but safe server-side filters. To this end, it
often makes sense to make the results of SA analysis available to Sieve scripts
and there are extensions defined for exactly this purpose.
Thats an implementation specific application. Its not a generic model.
As for milter, it's a general-purpose MTA callout mechanism, not a filtering
facility per se.
Same idea though, which suggest that this doc/diagram is too locked into
a model the authors and their peers are used to seeing.
My point is simple, there will be people who see this and begin to
wonder if they are "wrong" because it doesn't fit what the authors
thinks is the model of the internet.
Since filtering is a BIG part of the whats uniquelly different from
system to system, to lock in SIEVE in that specific part of the diagram
is just not correct in my opinion.
I'll posit that although there aren't as many independent vendors for
Spamassassin or procmail, that more mail actually gets filtered by them
than by SIEVE.
Not in our customer experience. If I come across 1 SIEVE system, that
would be a lot. Honestly. Our customers use our BASIC language p-code
MFA engine and most use 3rd party tools that add rules like spawning SA
and other remote service filtering ideas.
Of course, I'm in danger of being looked at as small potatoes, which I
accept, but we have to deal with the ouside world too, and by far, SIEVE
is not a common concept we come across.
SA and the multitude of other commercial and noncommercial antispam and
antivirue facilities undoubtedly process far more mail than Sieve
implementations do, but as I say, their roles are complimentary, not
competitive.
Right, even more reason why SIEVE doesn't fit in that diagram.
Of course, this is just my opinion for what I think should be a more
proper generic Internet EMAIL Architecture Model outline. In my view,
people begin to see something that isn't part of their own environment,
they tend to put it aside thinking it doesn't apply.
--
HLS