Here are my comments (at least so far) on the document:
>3 Appropriate Use Policy
I would remove this entire section. It is completely about policy and
not technical standards. Furthermore the policy it promulgates is a
very simple and limited view. It doesn't recognize the notion that an
AUP may be subject to negotiation between ISP and customer. For
example how do you publicize a policy if some customers have
negotiated exemptions or special provisions.
>5.3 Open Mail Relay
>
> An SMTP mail server is said to be running as an 'open' mail relay if
> it is willing to accept and relay to non-local destinations mail
> messages that do not originate locally (i.e., neither the originator
> nor the recipient address is local). Such open relays are frequently
Actually many spammers will forge a source address to be from the
institution running the relay. The common definition being used these
days by the anti-spam vigilantes is "an SMTP server which will accept
mail from outside the IP address block of its own institution that
permits delivery of e-mail to people outside of its institutional
domain *or* an SMTP server that accepts e-mail from other SMTP servers
inside a an IP address block that itself will accept mail from outside
its IP address block and then attempt to deliver it to outside the
domain."
In general the only way for an institution to avoid being labeled an
open relay given this constraint effectively requires that it maintain
an official mail "hub" or relay and block all port 25 access into its
IP address block. For an educational institution (and others) this is
quite an onerous and unreasonable burden.
Having said all that....the statement later:
> ISPs should also strongly encourage their customers to disable open
> relaying on their mail servers.
should probably not be there. I believe that the state of "play" with
open mail relays vs. the spammers vs. the anti-spam vigilantes is
sufficiently unstable that we, the IETF, should not be making
recommendations of a policy nature such as this one.
>5.4 Message Submission
>
> Message submissions should be authenticated using the AUTH SMTP
> service extension as described in the "SMTP Service Extension for
> Authentication" [RFC2554]. ...
Is this stuff really deployed? I would be happier if there were words
that make it plain that this should be used when client software is
truly ready for it.
Perhaps this section should be re-worded to briefly explain what message
submission is, followed by a statement that client support is
anticipated eventually followed by a recommendation to support it as
well as traditional methods in anticipation of the day when it can be
made mandatory.
-Jeff
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature