Re: email "Common Operating Group"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 
> 
> Bill Sommerfeld wrote:
> 
> >> I like Keith's terms MON / MRN (mail originating / receiving
> >> networks) better, because seen as sets of systems they can be
> >> different.  An outsourced backup MX would be still a part of
> >> the "MRN" (if I got this right), but not belong to the same
> >> "COG".  MUAs also belong to one or more MONs / MRNs, but not
> >> necessarily to the same "COG" as the correponding MSA / MDA.
> > 
> > Yup.
> 
> 
> 1. Having the term refer to either origination or reception means we need 
> multiple terms.  I am seeking a single term.

I coined separate terms because I found that I could not clearly
describe the appropriate behavior using a single term.  The
requirements for processing of mail by an origination network are
different than those for a reception network.

When I coined MON and MRN I did so after first trying to refine the
text without defining new terms, and failing to produce something that
seemed sufficiently clear or precise.   Of course, someone else might
have better skill.

> 2. Having the termr efer to either origination or reception ignores transit 
> operations.  The term needs to cover those activities, too.

I haven't seen a need to include transit operations in either case, and
to me it seems like that would make it muddier.  The whole assumption
behind discouraging third-party relaying is that a mail network should
only process messages that were either originated from within that
network, or intended for a recipient within that network.  This 
implies that "transit" operations - which I take to mean a relay by an
MTA that has no relationship with either the originator or the
recipient - are discouraged. 

Even when mail handling is "outsourced", it must still follow rules
appropriate to the role it is performing - whether it is relaying the
mail on the originator's behalf (because it has an arrangement with the
originator) or on the recipient's behalf (because it has an arrangement
with the recipient).  If the network isn't relaying the mail on the
behalf of either party, that's third-party relaying.   Even when the
same mail network provides service to both the sender and recipient,
it's important to implement sender and recipient policies in the right
order.  If the sender (or sender's domain) requires that outgoing mail
be authenticated,  it doesn' t matter whether the recipient is handled
by that mail network or not - the submission should still be rejected.
Similarly, if the recipient (or recipient's domain) has a policy of
rejecting mail according to certain criteria, the fact that the message
was sent from within the same network is irrelevant, because if both  -
the message should still be rejected.

> 3.  Whether an outsourced activity falls under the administrative policies 
> of the client or the operator is an interesting question, and not one with 
> an obvious answer.  So the common term needs to permit either answer.

Or perhaps trying to describe both behaviors using only one set of
terms obscures an answer that would otherwise be obvious.

Keith

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]