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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.