Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt]
2007-03-09 19:22:09
Dave,
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
--
HLS
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.
Folks,
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...
Dave,
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.
--
HLS
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: ADMD, (continued)
- Re: ADMD (was: Re: I-D ACTION:draft-crocker-email-arch-06.txt), Valdis . Kletnieks
- Re: ADMD, Dave Crocker
- Re: ADMD, David MacQuigg
- Re: ADMD, Dave Crocker
- Re: ADMD, David MacQuigg
- Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt], Dave Crocker
- Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt], Hector Santos
- Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt],
Hector Santos <=
- Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt], Frank Ellermann
- Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt], ned+ietf-smtp
- Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt], Valdis . Kletnieks
- Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt], Hector Santos
- Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt], Frank Ellermann
Re: [Fwd: I-D ACTION:draft-crocker-email-arch-06.txt], Hector Santos
[Fwd: I-D ACTION:draft-crocker-email-arch-06.txt], Dave Crocker
|
|
|