[Top] [All Lists]

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

2007-03-09 19:22:09


One last comment to illustrate my point.

In a similar vain, you have DSN there for the bounce stuff. Again, this is a specific way of doing a bounce, yet not everyone uses this specific RFC to do a bounce. It is relatively recent and not required for operations. So technically, in a similar argument for generality, it should not be there.

However, the difference with DSN vs SIEVE, is that DSN is a pretty much a generic term and can be substituted for a bounce concept.

Not so with SIEVE. When you specifically say "SIEVE," you are talking about a specific, cryptic computer language, that just so happens to be a RFC, hence a "formal standard" document, but nevertheless it is not the "common standard" used for mail filtering across the board.

With DSN, again, a specific formal RFC standard and method for generating a bounce, although it is not used across the board, the DSN acronym is generic enough for every system to understand that it is a bounce processor.

You can't say that about the way you have SIEVE embedded in that diagram.

If the problem is that we don't have a "pseudo" industry understanding for the acronym MFA, like we do for MUA, MTA, MSA, MDA, etc, then I can see why you want SIEVE. But changing it to MFA and defining MFA would be more technically appropriate in my book.

Thats it. Thanks


Hector Santos wrote:

Dave Crocker wrote:

What about SpamAssassin filters, and Sendmail Milters that do filtering?

They are not doing the same job as Sieve.


Even if they were, I need to repeat that this diagram and this section of the document are explicitly constrained to formal standards.

It's not that discussing the broader range of pragmatic and equivalent mechanisms isn't also valuable. It is that it makes the task too large for this document.

In fact, I think it opens the door to a book, not an IETF architecture document...


I think overall you are right, but out of everything in there, SIEVE is the ODD BALL and the way you have outlined, not only does it not apply to many systems, it just isn't used as a formal standard like everything else that is on that diagram.

In other words, there is no getting away from RFC-x822 and RFC-x821 and the pretty much standard macrocosms, MSA, MUA, MTA, etc are just that, acronym's that can fit most, if not, all email implementation models. The flow is pretty generic.

But then all out of sudden, you throw in a concept like SIEVE that just doesn't fit with everything else there in a general, generic way. Not everyone uses SIEVE and more importantly similar MFA engines would not necessarily be where you have SIEVE embedded in the diagram.

It is only there because the author(s) and their peers are familiar with with this, which is fine, but many systems are not familiar with the same thing.

You ask for technical opinion, you got it.

Thanks for allowing me to express my opinion.