Re: Security Expectations for Internet Service Providers to BCP

[Bill Woodcock <woody@zocalo.net>]

Sorry, I'm speaking from a position of ignorance regarding the status of
the document and what's already been incorporated in what you're
reviewing.  The last draft I've read was draft 3, from February, prior to
the meeting, and that's what Randy had asked about, I assume that's what
you're looking at as well.

It was my understanding from Adelaide that there were a small number of
primarily editorial changes that Tom was going to integrate before the
document was finished, subsequent to the Adelaide meeting.  If that's not
the case, you can ignore my comments.

    > I'd be happy with a SHOULD NOT. MUST just seemed a bit absolute,
    > especially given the RFC 2644 did not deem it appropriate to go this
    > far. I.e., is the WG really sure it wants the MUST NOT language?

Hm.  I guess this goes back to the question that argument about this
document has hinged on historically, and which is central to a lot of
BCPs, I guess...  Should the document specify a rigorous set of
requirements, such that many ISPs will not meet the letter of the
document, or should it be really open, and make everybody feel good
because they're able to say they meet its requirements, even if they're
not doing most of the things it recommends?  I tend toward the former,
since I'm able to make my company meet a lot of requirements, and I thus
benefit from a strict definition.  Other people have argued for a loose
definition because they could still claim compliance, then, without doing
any work.  You're not an ISP, so you should presumably have a more neutral
and objective view than any of us who've been arguing about it.

    > Section 5.4 talks about
    > message submission. What is the difference (technically) between
    > message submission and the following:
    
You're quite right; I guess the distinction between 5.3 and 5.4 isn't a
technical one...  5.3 describes a common problem, 5.4 proposes a solution,
so they're sort of categorically different...  I guess I'm not that happy
with it either.

How about wrapping the two up into one paragraph that comes down harder on
open relays, but defines authenticated mail submission as not being an
open relay?  For instance:

5.3 1/2  Email Relaying and Authentication

An SMTP mail server is said to be an "open relay" if it is willing to
accept unauthenticated email submissions addressed to domains which it
does not define as being for "local delivery," and retransmits them.  That
is, email of which neither the sender nor the addressee is served by an
account within the administrative scope of the mail server's operator.
Open relays are used by 'spammers' to inject their Unsolicited Bulk E-mail
(UBE) while hiding their identity.  Since this imposes an unrecompensed
burden on the Internet as a whole, network operators _MUST NOT_ operate
open relays.

The most frequent incentive for opening a relay is to allow mobile users
to submit outbound email to the same server as they travel from network to
network, without reconfiguring their MUA's SMTP deliver host each time
they move.  If this need must be met, it _SHOULD BE_ facilitated
through the use of AUTH SMTP...  [continuing on into what's now 5.4]

    > I.e, what does "local" mean in the context of the Internet?

I think it's in the context of an MTA...  "Local" is whatever's in your
sendmail.cf or equivalent, no?  Stuff that terminates via a local delivery
method, rather than being retransmitted by one of your external delivery
methods like SMTP or UUCP...

                                -Bill