----- Original Message -----
From: "Matthew Elvey" <matthew(_at_)elvey(_dot_)com>
To: "wayne" <wayne(_at_)midwestcs(_dot_)com>; "MXCOMP"
<ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Wednesday, March 31, 2004 12:30 AM
Subject: Re: plan for april 5th xmpp conference...
* I believe that the this is an easier problem to solve than the
RFC2822 header spoofing problems. The RFC2821 data is handled
almost entirely by programs and thus lends itself to verification
via programs.
I don't buy this. Besides which, RFC2822 headers are also handled almost
entirely by programs too.
The problem of "coupling" 2822 is that you are breeding new inertia or
development pressure for transport software writers to prematurely accept
mail for analysis.
The issue is lessen for an advanced systems with the ability to offer a DATA
stage hook to perform the mail content analysis dynamically with a dynamic
response at the protocol level.
However, in either mode (dynamic vs post) the potential waste of
payload/bandwidth issues can not be ignored in this mode of operation
If this coupling is being considered with an eye towards the future where it
might impose a new requirement to split the DATA command into HEAD and BODY,
then I don't have a problem with this on a both a technical and legal level.
I personally see this happening (this need) when Microsoft/YAHOO, whose
proposals required mail acceptance, inevitably becomes a widely deployed and
dominant mode of operation.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com