ietf-mxcomp
[Top] [All Lists]

Re: A new SMTP "3821" [Re: FTC stuff...........]

2004-12-04 20:14:11

----- Original Message -----
From: "Matthew Elvey" <matthew(_at_)elvey(_dot_)com>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
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





<Prev in Thread] Current Thread [Next in Thread>