----- Original Message -----
From: "Yakov Shafranovich" <research(_at_)solidmatrix(_dot_)com>
To: "Peter J. Holzer" <hjp-asrg(_at_)hjp(_dot_)at>
As a matter of fact, many RFCs include sections on how to deal with
violations and other "irregularities" in Internet protocols since they
occur and occur pretty often. For an example, see RFC 2821, section 6.3.
It is outlines these specifics, it its not unknown. it becomes a functional
defined specification or guideline.
In practice, most of the issues dealt with mail format conformity and
strict and proper usage of the MAIL FROM: (return path) for both transport
and gateways.
By far, most SMTP designers agree that if the MAIL FROM: is not intact, the
system will not WORK.
The mail format is more debated. There is only ONE requirement (per RFC
guideline) which our software respect. Each mail header must have:
To:
and once of the following:
Received:
From:
Date:
in order to be consider a valid RFC header.
Now, for our software, it does not mean the MAIL is reject, what it means is
that the it use the envelope information to fill it and add its own Message
Id, etc, etc, etc. (PS: Please don't off on a tangent with the above, the
complexity in the software logic engineered in our mail system to workaround
every piece of situation is not required to be discussed here)
Again, most of the concerns in practice are with mail content, as the
statement in that section says:
"These changes MUST NOT be applied by an SMTP server that provides an
intermediate relay function."
Is a very important for design criteria for making sure passthru operations
do not alter mail.
What we are talking about here specifically, is making sure the interface
points are followed.
What if the MAIL FROM: is not followed correctly?
What if the HELO/EHLO is not followed correctly?
What if the RCPT TO: is not followed correctly?
I believe this is your part. To help changes the SPECS to clarify strict
compliance at the interface points.
Otherwise, we are all beating a dead horse here and we are not going to
solve any problem (as a group). Trust me, vendors will begin solve the
problem and when there is a divergence of solutions. Bye Bye IETF! I've
seen it before where change was not met with the market needs. It will
happen again if you don't heed the advice.
If you don't clarify the specs, you are not helping developers solve the
problem for you.
---
Hector Santos
WINSERVER "Wildcat! Interactive Net Server"
support: http://www.winserver.com
sales: http://www.santronics.com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg