On Sat May 28 2005 13:19, David MacQuigg wrote:
I don't know what could be more clear than:
'''header fields SHOULD NOT be reordered when a message is transported or
transformed. More importantly, the trace header fields and resent
header fields MUST NOT be reordered, and SHOULD be kept in blocks
prepended to the message.
''' RFC-2821, section 3.6.
RFC 2821, section 3.6:
3.6 Domains
Only resolvable, fully-qualified, domain names (FQDNs) are permitted
when domain names are used in SMTP. In other words, names that can
be resolved to MX RRs or A RRs (as discussed in section 5) are
permitted, as are CNAME RRs whose targets can be resolved, in turn,
to MX or A RRs. Local nicknames or unqualified names MUST NOT be
used. There are two exceptions to the rule requiring FQDNs:
- The domain name given in the EHLO command MUST BE either a primary
host name (a domain name that resolves to an A RR) or, if the host
has no name, an address literal as described in section 4.1.1.1.
- The reserved mailbox name "postmaster" may be used in a RCPT
command without domain qualification (see section 4.1.1.3) and
MUST be accepted if so used.
I think you might mean RFC 2822.
It's clear -- if and only if one understands BCP 14 (a.k.a. RFC 2119).
In particular, note that "SHOULD" is a recommendation, not a requirement.
[...]
Agreed. My expectations are:
2) Trusted forwarders will follow the RFC-2821 requirements.
Note above re. the difference between "recommendation" and "requirement".
Note also that compliance with RFC N only applies to implementations which
are in fact compliant with the provisions of RFC N. It is one thing for a
vendor to claim compliance, it is another to achieve it with a particular
version and configuration, and it is yet another to guarantee it regardless
of configuration. Note well that there is nothing in a message that
indicates a claim of compliance (there may however be evidence of a failure
to comply, though it is not always clear where the blame lies). Finally,
note that there is no enforcement mechanism for provisions in RFCs, even
those which are "requirements"; compliance is purely voluntary. In
particular, there is no guarantee that all SMTP receivers comply with all
provisions of RFCs 821, 2821, and 2822. Some of those provisions are
mutually contradictory, and it is a known fact that the vast majority of
SMTP receivers in fact do not comply with some provisions of all of those
RFCs.
I also note that as there is no standard definition of "trusted forwarders",
there is a danger that there is an attempt at a circular definition, which
would be of no value.