Re: A new SMTP "3821" [Re: FTC stuff...........]
"Hector Santos" <[email protected]>
| Newsgroups | gmane.ietf.mxcomp |
|---|---|
| Organization | Santronics Software, Inc. |
| Message-ID | <003701c4da78$634ae580$6401a8c0@hdev1> |
----- Original Message ----- From: "Matthew Elvey" <[email protected]> To: "Hector Santos" <[email protected]> Sent: Saturday, December 04, 2004 9:34 PM Subject: Re: A new SMTP "3821" [Re: FTC stuff...........] > >1) EHLO/HELO validation > >2) MAIL FROM validation > >3) RCPT TO validation > >4) DATA validation, if any > >5) Mixed Validation > > > > > What is this? What are mixed validation or Mixed Policies? In short, it is coupling the validation logic of lets say what a MAIL FROM validation will produce vs a HELO validation will produce. It is illogical to have a "valid" result where another data point is invalid, vice versa. There are many other examples of mix policies. > >CSV concentrates on #1, gets lost on SMTP AUTH issues, > > > I 'm pretty sure you're confused. Can you point to what part of the > spec you're referring to, so we can make it clearer? > Legit MUAs only send mail to MTAs they authenticate to. This is the > only hop in which CSV suggests SMTP AUTH as *A* solution (not the solution) The above was an example of a MIX policy. CSV presumes to validate the client domain name when it is possible there is an incoming ESMTP AUTH session, in which case, in my technical opinion, CSV does not apply. A pending mix policy may also exist at MAIL FROM and certainly at RCPT TO. Hope this helps. Sincerely, Hector Santos, CTO Santronics Software, Inc. http://www.santronics.com 305-431-2846 Cell 305-248-3204 Office