Mailing List Archive

At 03:45 PM 1/14/2008 +0100, Alessandro Vesely wrote:
>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.

I'll be happy to contribute to the this page, but first we really need to resolve some basic differences over the definition of Border. Here is what I would suggest: http://open-mail.org/Definitions#Border_MTA I am also considering some changes in my page to better conform with our discussions here. As you pointed out, the Receiver really should be linked directly to the Transmitter.

As Frank said, our terminology reflects our "ideology". SPF was originally designed with the understanding that there was a well-defined border, and forwarders were only "edge cases". Now there is more emphasis on forwarding. Crocker seems to have the opposite point-of-view, that a typical mail transfer involves numerous, unrelated ADMDs.

I think these are just two views of the same world. We can certainly add "secondary borders" to our diagram, and Crocker can certainly draw a double line between two of his ADMDs. The difference is really just emphasis. Folks favoring IP-based authentication methods tend to think of a single border. Folks favoring signature-based methods tend to think of numerous borders.

I would like to hear more from the other members of this community. Is there a consensus?

>>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.

I think adding one forwarder is sufficiently general. If we can handle one, we can handle many.

>>>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

I would change "MDA" to "Receiver1", since MDA means Mail Distribution Agent. The MDA really should be at the end of the line.

>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 don't understand these two roles, and how they differ from the role of Recipient as we have it currently defined. Perhaps an example would help.

>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.

Maybe we could define different classes of mail: First Class, Bulk, and Forwarded. There could be a special blacklist for spammers who try to masquerade as forwarders. But I digress. Let's finish our discussion of Mail System Terminology.

-- Dave

-------------------------------------------
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=85678986-506ba4
Powered by Listbox: http://www.listbox.com

********** Models for Mail Handling Systems ****** Rev.1 24-Jan-08

A/B Roles A and B both played by the same Actor
--> Direction of mail flow (no relationship implied)
==> Direct relationship between Actors (e.g. a contract)
~~> Indirect relationship (e.g. both directly related to Recipient)

Simple Setup with four Actors:

|---- Sender's Network -----| |-- Recipient's Network -|
/
Sender(s) ==> MSA/Transmitter --> / --> Receiver/MDA ==> Recipient
/
Border

Simple Forwarding is quite common:

|-------- Recipient's Network ---------|
/
--> / --> Receiver/Forwarder ~~> MDA ==> Recipient
/
Border

Chain Forwarding should be discouraged:

|------------ Recipient's Network ------------|
/
--> / --> Receiver ~~> Forwarder(s) ~~> MDA ==> Recipient
/
Border

Open Forwarding must be banned:

/ / |-- Recipient's Network -|
--> / --> Forwarder --> / --> Receiver/MDA ==> Recipient
/ /
Border Border

******************************************************************

Responsibilities assigned to each role - Rev. 0

Sender
- Originate messages
- Provide a password or other means of authentication

MSA - Mail Submission Agent
- Authenticate the Sender
- Manage Sender accounts

Transmitter
- Spam Prevention
- rate limits, content analysis, alerts
- respond to spam reports
- maintain reputation
- Authentication
- RFC compliance
- IP authorization (SPF, SID, CSV, ...)
- signatures & key management (DKIM ...)

Receiver
- Block DoS
- Authenticate Transmitter|Sender
- HELO, Return Address, Headers, Signature
- reject forgeries
- Assess reputation
- whitelist reputable Senders
- Filter spam
- Add authentication headers
- Manage Recipient accounts/options
- whitelisting, blacklisting, filtering, blocking, forwarding
- Process spam reports

Forwarder
- Authenticate upstream Agent
- Set up forwarding to downstream Agent
- check RFC compliance
- set up authentication records
- submit forwarding request, wait for approval
- Manage Recipient accounts
- maintain database of forwarding addresses
- suspend account when a message is rejected
- communicate w Recipient re " "
- Maintain reputation as a trusted Forwarder
- certifications

MDA - Mail storage and Distribution Agent
- Authenticate upstream Agent
- Sort and store messages
- Provide access for Recipients
- POP3, IMAP, Webmail
- Manage Recipient accounts/options
- Relay spam reports to Receiver (or don't accept them)

Recipient
- Set up accounts with each Agent in the MRN
- Select options in each account
- Report spam to Receiver

-------------------------------------------
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=89690083-4afe56
Powered by Listbox: http://www.listbox.com

David MacQuigg wrote:
> A/B Roles A and B both played by the same Actor

I'd use "Agent" rather than "Actor" for specifying an entity that is
either a client or a server, as it is more commonly used in that sense.

> --> Direction of mail flow (no relationship implied)
> ==> Direct relationship between Actors (e.g. a contract)
> ~~> Indirect relationship (e.g. both directly related to Recipient)
/ cooperating agent on the same box

> Simple Setup with four Actors:
>
> |---- Sender's Network -----| |-- Recipient's Network -|
> /
> Sender(s) ==> MSA/Transmitter --> / --> Receiver/MDA ==> Recipient
> /
> Border
>
> Simple Forwarding is quite common:
>
> |-------- Recipient's Network ---------|
> /
> --> / --> Receiver/Forwarder ~~> MDA ==> Recipient
> /
> Border

While that diagram is correct when Forwarder ~~> MDA uses the LMTP
protocol, more commonly there is an MTA listening to the Forwarder,
thus that should rather be Forwarder ~~> Receiver/MDA.

> Chain Forwarding should be discouraged:
>
> |------------ Recipient's Network ------------|
> /
> --> / --> Receiver ~~> Forwarder(s) ~~> MDA ==> Recipient
> /
> Border

It is not much different than the previous case, and there may be
legitimate uses of that schema.

> Open Forwarding must be banned:
>
> / / |-- Recipient's Network -|
> --> / --> Forwarder --> / --> Receiver/MDA ==> Recipient
> / /
> Border Border

A second border is not possible, if we define the border as the point
across which mail is relayed without any specific arrangement or
agreement. That means a messages is sent through a border because
the domain in its RCPT envelope address indicates the relevant
Receiver as the MX in the global DNS.

Inside a MON one could run a faked DNS that arbitrarily assigns some
smart host to any external domain's MX record, for the mere purposes
of running existing MTA software without having to configure specific
routes for each mail server inside the MON: this _is_ a kind of
contract.

Looking up an alias is obviously some kind of contract.

Therefore the uniqueness of the border is a consequence of the
uniqueness of the MX. If there are more MXes on a given message's
path, the border lies before the first one. Indeed, establishing a
backup MX is some kind of contract.

Actually, what must be banned are Forwarders that just replace the
envelop RCPT address (a.k.a. alias-expansion.) Having a forward
address configured somewhere is certainly some kind of contract. The
recipient cannot verify, inquiry, modify or delete the configured
value. It is not clear where DSNs should go. That's why it is broken
and must be banned.

> ******************************************************************
> Responsibilities assigned to each role - Rev. 0

This part is quite rough. It may help understanding what each role
means, but isn't really necessary for that purpose.

> MDA - Mail storage and Distribution Agent

I'd stick to "Mail Delivery Agent." The role description below does
not quite fit in with the standard description given, e.g. in rfc5068.
Perhaps some of my comments above originate from this misunderstanding.

> - Authenticate upstream Agent
> - Sort and store messages
> - Provide access for Recipients
> - POP3, IMAP, Webmail
> - Manage Recipient accounts/options
> - Relay spam reports to Receiver (or don't accept them)

-------------------------------------------
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=89825691-a6d1b3
Powered by Listbox: http://www.listbox.com