On Thursday, April 03, 2003 4:01 AM, william(_at_)elan(_dot_)net
[SMTP:william(_at_)elan(_dot_)net]
wrote:
I'm not advocating either #1 or #2 from your list below in either the
presentation or notes - both are just the basic or summary of some
non-crypto source-authentication approaches but not speciying exact details.
Ok.
As far as my proposal it'd be a lot more complex and mail tracking with
dns would be just one component of it (one of about 8 drafts) and I'n not
advocating use of either envelope "MAIL FROM" or header "From", I'd rather
actually create new header for authenticated sender and only when this new
header is absent then heder "From:" can be used. But envelope "MAIL FROM"
is changeble for in-between mail servers (maillists, forwarders) and hence
it should be used on per-transaction authentication (where as header "From"
be be used in authentication the source). When I find time to write all these
drafts, I guess you will see what I mean - right now I'v presented bits
and pieces and it may seem like there are scope issues, overall I
think this is eliminated (I guess by introducing more complexity...).
Yes, I however think that IP as SMTP sender authentication can always be
useful, regardless of header re-writing. If it's in a net range where it is
not defined as an SMTP origination source other servers in the MTS should
consider (based on the status of it's implementation) not accepting, with some
error code returned.
And I (and I'm sure other members of reseach group too) would more then
welcome differentanalysis approaches. In fact at some point we will need
to come with list of what and how needs to be analyzed and then have it
done for each proposal and having different parallel analysis done would
be quite usefull. So it maybe good idea to write out more specs on how you
would analyze a proposasl, though having requirement is often necessary in
order to do it.
I agree (Russell Brand and I are starting our dialog on requirements at this
moment, I think a more detailed draft will emerge soon).
-e
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg