[Top] [All Lists]

Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]

2007-03-09 18:15:59

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

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.