Hello,
Boy, its amazing how much is discussed and unless I am missing something, I
don't see any real conclusion or general direction. I'm sure I'm off base,
but in my view, I think the continued discussion on "RFC 2822" relationship
as far as the SMTP transport model is concerned is going off on the wrong
direction for a solution.
For one thing, there is no consensus on "format" and to use a model of data
that X products do this or that really does not give you a 100% guarantee
that it is how everyone behavior.
I believe the DNS-based validation needs to remain at the transport level
where is a consistent and fixed model that we can work with. There is where
the majority is at and this where this majority can be eliminated.
Now, with that said, this does not suggest any additional validation can not
be applied but in my view this is augmented, secondary, SMTP-transport
independent validation process.
Vendors, such as Microsoft and Santronics, who have complete control of
their resources from MUA to MTA, etc, can easily see the benefits as a
whole. But I am speaking as a general developer who recall the days where
we did not have control of their resources, and might only provide a
"sub-system," for example, just a generic SMTP mail server.
The fact is, there is a viable technical solution that SMTP can address
here. It doesn't need RFC 2821, however, that does not say, an
implementation can not use it as well if they choose to do so.
The fact is, there is no consistency with a RFC 2822 based solution. A
dependency on this solution will mandate an even greater unrealistic desired
behavior by all parties. I certainly hope that a "decision" is not made
based on a dataset collected illustrating a particular desired end-result
where there is no guarantee to be this way.
We need to get away from individual "external" bias of what one may think
"the world behaves" and solve this problem at the first level where there is
sound, fixed technical protocol.
This is not a pop shot at Microsoft, I love Microsoft, but they don't have
the great engineers with time-tested system engineering training.
Caller-id or CEP and the call for greater end-point analysis is yet another
strategy that has a greater dependency on integration at the expense of the
security of the middle ware. Hackers are going to exploit this method
because now they will have 1 foot in the door. All they need to do is
satisfy the weak data integrity which is inevitably going to happen
regardless of any proposal - don't lie or spoof the data. Unless CEP is
going to 100% verify the complete sender address, not just a simple match of
2821 and 2822 sender information, it means that the pressure is not on post
SMTP systems to perform a validation that can already be done on at SMTP.
Again, this is not to say an implementation can not use the 2822
information, but it is at another level, a level that I don't think is
consistent with what we are trying to do.
Finally, we use a CBV (call back verifier) and this has undoubtedly proven
to be best method verify the validity of complete return path address - it
is either rejected or accepted. We have been using this now for over 6
months and its going take something better than a RFC 2822 analysis to
eliminate this method. The production data showing a CBV works is simply
too overwhelming to ignore. NOTE: I am not advocating a CBV. It is the
proof of concept of what this "black box" dynamic SMTP address verification
provides is that is important here.
I think we need to focus a RFC 2821 solution, at the very least, as the
first focus item to address. Everything else follows after that.
Thanks for your time
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com