Re: Sender's Declaration of Identity2005-05-17 15:08:51At 02:27 PM 5/17/2005 -0400, Hector Santos wrote: ----- Original Message ----- From: "David MacQuigg" <david_macquigg(_at_)yahoo(_dot_)com> > Here is an incoming email with no ID declaration. > > EHLO mailserver7.bigforwarder.com > MAIL FROM:<bob(_at_)sales(_dot_)some-company(_dot_)com> > > What do you do next if you want to authenticate this message? Dave, That should depend on the server, not the client. However, if I think where you going with this (and this is not the say I agree with it), what you are looking for the server expose to the client how the client can be authenticated: The more propery way to do this today with ESMTP would be for the server to expose what methods it support: C: EHLO mailserver7.bigforwarder.com S: 250-hostdomain.com, Plesase to meet you. S: 250-SIZE 5120000 S: 250-ETRN S: 250-ID SPF1 SPF2 CSV S: 250-AUTH CRAM-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1 S: 250-AUTH=LOGIN S: 250 HELP So for this server, it supports SPF1, SPF2 and CSV. The compliant client can choose one. Example #1 C: EHLO mailserver7.bigforwarder.com S: 250-hostdomain.com, Plesase to meet you. S: 250-SIZE 5120000 S: 250-ETRN S: 250-ID SPF1 SPF2 CSV S: 250-AUTH CRAM-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1 S: 250-AUTH=LOGIN S: 250 HELP C: ID SPF1 somedomain.com S: 250 Validated! Continue Example #2: C: EHLO mailserver7.bigforwarder.com S: 250-hostdomain.com, Plesase to meet you. S: 250-SIZE 5120000 S: 250-ETRN S: 250-ID SPF1 SPF2 CSV S: 250-AUTH CRAM-MD5 LOGIN PLAIN PLAIN-MD5 SHA-1 S: 250-AUTH=LOGIN S: 250 HELP C: ID CSV somedomain.com S: 551Sorry, not validated. Do not continue. But might be conflictive with the state flow with our CSV is done, Dave can answer that. Also, I would personally suggest introduce optional enforcement concepts that makes the proposal stronger in my view. Example #3 C: EHLO mailserver7.bigforwarder.com S: 250-hostdomain.com, Plesase to meet you. S: 250-ID SPF1-REQ SPF2 CSV S: 250 HELP Which would suggest that SPF1 is required if the optional SPF2 or CSV is not used by the client. To further this idea, throw in a RES (restricted) and AUTO modifiers. Example #4 C: EHLO mailserver7.bigforwarder.com S: 250-hostdomain.com, Please to meet you. S: 250-ID SPF1-REQ SPF2 CSV-RES S: 250 HELP This would suggest that SPF2 is optional, CSV is restricted to certain IP addresses (or domains) and is required if the client falls in this classification. Otherwise SPF1 is required. Example #5 C: EHLO mailserver7.bigforwarder.com S: 250-hostdomain.com, Please to meet you. S: 250-ID SPF1-AUTO SPF2 CSV-RES S: 250 HELP This would suggest that SPF2 is optional, CSV is restricted to certain IP addresses (or domains) and is required if the client falls in this classification. Otherwise SPF1 is automatically applied, ID is not required: Example #6 C: EHLO mailserver7.bigforwarder.com S: 250-hostdomain.com, Please to meet you. S: 250-ID SPF1-AUTO SPF2 CSV-RES S: 250 HELP C: MAIL FROM: <reverse-path> S: 451 Sorry, this DOMAIN failed SPF1 Example #7 C: EHLO mailserver7.bigforwarder.com S: 250-hostdomain.com, Please to meet you. S: 250-ID SPF1-REQ SPF2 CSV-RES S: 250 HELP C: MAIL FROM: <reverse-path> S: 551 Sorry, Please Provide ID command Example #8 C: EHLO mailserver7.bigforwarder.com S: 250-hostdomain.com, Please to meet you. S: 250-ID SPF1-REQ SPF2 CSV-RES S: 250 HELP C: ID SPF2 pra-domain.com S: 250 pass! Example #9 C: EHLO mailserver7.bigforwarder.com S: 250-hostdomain.com, Please to meet you. S: 250-ID SPF1-REQ SPF2 CSV-AUTO S: 250 HELP [CVS checking done] S: 551 - Sorry, you are not validated etc. etc. So basically, you need to map the behavior of all methods and then come up with the functional specification on how the SMTP server will behave. Now, will it work? Probably not. For many reason, but the most important one from my stand point is that it is a big change and if we are considering a big change, we might as well go all the way with other more stronger methods. But I do think if you continue with the proposal, you should consider the modifies REQ, RES and AUTO. What worries me about "going all the way" and including lots of nice options, is that the history of this project shows that even the most trivial of agreements among the different factions are impossible to negotiate. The ID declaration is about as simple and "non-partisan" as I can make it, and you can see the negative reactions that is generating. Imagine the arguments over which keywords (SPF1, SPF2, SENDERID(C), CSV, REQ, RES, AUTO, ... ) will be designated as IANA approved!! If there is way to get the benefit of these options without adding it all to SMTP, and I believe there is, then we should spend our limited time and energy on just getting a simple, neutral way to declare an ID. -- Dave ************************************************************ * * David MacQuigg, PhD email: david_macquigg at yahoo.com * * * IC Design Engineer phone: USA 520-721-4583 * * * * Analog Design Methodologies * * * * 9320 East Mikelyn Lane * * * * VRS Consulting, P.C. Tucson, Arizona 85710 * ************************************************************ *
|
|