David MacQuigg wrote:
> Starting a new thread, as there seems to be some serious
> interest in this topic.
I've created http://www.openspf.org/Community/Glossary and
added a few term's tentative definitions. Please feel
free to amend/expand that at any time.
> Here is what we have so far for a Basic Mail Handling System.
> /
> Sender(s) --> Transmitter--> / --> Receiver --> Forwarder(s) --> MDA --> Recipient
> /
> Border
>
> This is mostly an Administrative Level description, although
> the terms Transmitter, Receiver, and MDA are borrowed from
> the Machine Level description. We could use phrases like
> Receiving ADMD, or Mail Distribution Service, if the
> distinction is important. An MDA might handle such functions
> as mail storage, webmail, POP and IMAP access, virus removal,
> etc., and it seldom matters whether it is one machine or
> many.
>
> A minimum mail system includes at least an MSA (Mail
> Submission Agent), a Transmitting MTA, a Receiving MTA, and
> an MDA. The MSA and Transmitter could be one machine, and
> the Receiver and MDA could be another. There are always at
> least two machines and a Border.
If we focus on a single transaction, we can say there are
_exactly_ two (possibly coincident, e.g. if using localhost)
machines and one border between them. On the next hop, the
previous receiver becomes a transmitter (in a generic sense)
and we have a new border that defines its relationship with
the new receiver.
The difficulty stems from the need to draw multi-hops
diagrams that are general enough for the discussion at
hand.
>> Borders are particularly insidious for SPF. "ADMD" has
>> different meanings when its administrative management
>> affects DNS, IPs assignment, or SMTP configuration. In
>> addition, large organizations are partitioned into internal
>> subunits, which may wish to carry out SPF checking one
>> against the other. I don't think we can pull out any useful
>> topology from that.
>
> Can we at least sub-divide the mess into an MON and an MRN,
> with a clearly defined Border? I really don't like the idea
> that there are Transit ADMDs, floating in cyberspace, not a
> part of either MON or MRN. I would call such networks ORNs
> (Open Relay Networks), to put them on the same level as MONs
> and MRNs. I don't think they belong in any legitimate mail
> system.
We can add terms but we don't need to, until they don't enter
the discussion. The Basic Mail Handling System diagram above
may be complicated with the addition of a second "target" MTA
that the forwarder forwards to, e.g.
/
... --> MDA --> Transmitter2 --> / -->Receiver2 --> etc...
/
Border2
Those Transit ADMDs out there are difficult to characterize.
"Open Relay Networks" is a bit crude: An open relay certainly
results in a transit ADMDs, but most of them are not actually
open relays, in the classic sense of the term.
Someone has configured a forwarding mechanism, supplying a
target email address along with any credentials required for
fulfilling that task. "The person concerned", as we may call
the owner of the target mailbox, is not necessarily the same
person as "the perpetrator" who materially carried out the
configuration task. Are such terms needed?
I hope there won't be any "Forwarding Mail Transfer Protocol
(FMTP)" as I don't like protocol bloat. However, something
needs to be defined to make forwarding possible in the face
of spam.
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=85614786-f8397a
Powered by Listbox: http://www.listbox.com
> Starting a new thread, as there seems to be some serious
> interest in this topic.
I've created http://www.openspf.org/Community/Glossary and
added a few term's tentative definitions. Please feel
free to amend/expand that at any time.
> Here is what we have so far for a Basic Mail Handling System.
> /
> Sender(s) --> Transmitter--> / --> Receiver --> Forwarder(s) --> MDA --> Recipient
> /
> Border
>
> This is mostly an Administrative Level description, although
> the terms Transmitter, Receiver, and MDA are borrowed from
> the Machine Level description. We could use phrases like
> Receiving ADMD, or Mail Distribution Service, if the
> distinction is important. An MDA might handle such functions
> as mail storage, webmail, POP and IMAP access, virus removal,
> etc., and it seldom matters whether it is one machine or
> many.
>
> A minimum mail system includes at least an MSA (Mail
> Submission Agent), a Transmitting MTA, a Receiving MTA, and
> an MDA. The MSA and Transmitter could be one machine, and
> the Receiver and MDA could be another. There are always at
> least two machines and a Border.
If we focus on a single transaction, we can say there are
_exactly_ two (possibly coincident, e.g. if using localhost)
machines and one border between them. On the next hop, the
previous receiver becomes a transmitter (in a generic sense)
and we have a new border that defines its relationship with
the new receiver.
The difficulty stems from the need to draw multi-hops
diagrams that are general enough for the discussion at
hand.
>> Borders are particularly insidious for SPF. "ADMD" has
>> different meanings when its administrative management
>> affects DNS, IPs assignment, or SMTP configuration. In
>> addition, large organizations are partitioned into internal
>> subunits, which may wish to carry out SPF checking one
>> against the other. I don't think we can pull out any useful
>> topology from that.
>
> Can we at least sub-divide the mess into an MON and an MRN,
> with a clearly defined Border? I really don't like the idea
> that there are Transit ADMDs, floating in cyberspace, not a
> part of either MON or MRN. I would call such networks ORNs
> (Open Relay Networks), to put them on the same level as MONs
> and MRNs. I don't think they belong in any legitimate mail
> system.
We can add terms but we don't need to, until they don't enter
the discussion. The Basic Mail Handling System diagram above
may be complicated with the addition of a second "target" MTA
that the forwarder forwards to, e.g.
/
... --> MDA --> Transmitter2 --> / -->Receiver2 --> etc...
/
Border2
Those Transit ADMDs out there are difficult to characterize.
"Open Relay Networks" is a bit crude: An open relay certainly
results in a transit ADMDs, but most of them are not actually
open relays, in the classic sense of the term.
Someone has configured a forwarding mechanism, supplying a
target email address along with any credentials required for
fulfilling that task. "The person concerned", as we may call
the owner of the target mailbox, is not necessarily the same
person as "the perpetrator" who materially carried out the
configuration task. Are such terms needed?
I hope there won't be any "Forwarding Mail Transfer Protocol
(FMTP)" as I don't like protocol bloat. However, something
needs to be defined to make forwarding possible in the face
of spam.
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311532&id_secret=85614786-f8397a
Powered by Listbox: http://www.listbox.com