On Wed, 8 Jun 2005, Ned Freed wrote:
>> A practical issue I have with this doc is that the recommendations are
>> relatively few, and most of them are rather generic or vague.
>> Haven't we learned more on email BCPs by now?
>
> What we have learned and what we are able to reach consensus on are two very
> different things.
My point is that when we are writing a document like this, making it
intentionally very generic and vague seems much less useful.
And my point is that a less generic document we cannot reach consensus on
is and which therefore cannot be published of no use at all to anyone.
It may be difficult to get to a consensus what the BCP should be, but
hopefully what people have learned could be documented in a
non-normative way (i.e., a list of tradeoffs/background information).
This could be accompanied in a "Discussion" paragraph or two for each
vague item, for example.
My understanding is that a very large amount of effort and time was needed to
get this far. You are now proposing that even more effort and time be expended
in hopes that consensus can be driven a bit further in a few cases.
Sorry, I don't think it is worth it.
>> For example, this document says nothing on backup MX's accepting
>> mail for accounts which do not exist, just a very generic:
>
>> o MDAs SHALL NOT accept mail to recipients for which that MDA has no
>> arrangement to perform delivery.
>
> No doubt because I've seen no consensus whatsoever as to how this
> (very thorny) issue needs to be handled. If there is an agreed best
> current practice here waiting to be documented I'm unaware of what
> it is.
So, one could at least describe the non-existence of such best
practice?
Of course you could. The question is whether it is worth delaying this
specification in order to capture a group of such practices, none of which are
going to be recommended practices.
>> One generic question: what about the case where an organization X has
>> backup MX at ISP Y? How will that reflect to:
>
>> o For email being received from outside their local operational
>> environment, email service operators MUST distinguish between mail
>> that will be delivered inside that environment, from mail that is
>> to be relayed back out to the Internet. This allows the MTA to
>> restrict this operation, preventing the problem embodied by "open"
>> relays.
>
> It means the backup MX needs to be able to distinguish addresses
> associated with the destination environment and addresses that
> aren't. This functionality is readily available in most mail
> software.
I didn't make this point clearly, so let me try to state the initial
issue: "MUST distinguish between mail that will be delivered" seems
ambgiuous enough so that it could mean only that the server is
responsible for example.com, not that the server needs to know all the
user(_at_)example(_dot_)com accounts which will be used for final delivery.
That ambiguity is intentional, given that there are plenty of cases where it
isn't practical for backup MXes to know all the valid accounts.
As the document's use of basic terms like "delivery" are not
unambiguous enough, careful wordsmithing and clarification appears
to be needed.
Then please provide those clarifications. It looks to me like you're still
wanting to see the backup MX issue addressed at a level of specificity there is
no concensus for.
If the interpretation is what you write, more verbiage could still be
helpful. Is this really available in most mail software? I at least
would appreciate such feature and must have missed it so if you know
how to do this w/ sendmail for example, I'd appreciate an example
(off-list).
Sorry, I don't do sendmail config, but a google search turned up plenty of
pages discussing how to do it in sendmail. It's essentially a one line addition
in PMDF, JESMS, Postfix, and exim. (A rewrite rule addition in PMDF or JESMS,
an addition to the relay domains list in Postfix and exim.) I'm pretty sure its
easy to do in qmail, but I didn't bother to check the specifics.
>> Mostly editorial comments:
>
>> 1) Is the scope of the title, "Email Submission Between Independent
>> Networks", too narrow, as the document discusses relaying and delivery
>> BCPs as well?
>
> But both are discussed within the context of messages being sent between
> networks.
Maybe we agree then that the document actually talks about more than
just mail submission? (and the title is not accurate)
I guess I could live with "Email transfer" or something similar.
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf