Mailing List Archive

Michael Deutschmann wrote:

> The relay at the sender's border is called a "smarthost".

AFAIK a "smarthost" is what's today also known as "MSA":

A relay knowing what to do with mails going "elsewhere"
from the POV of the sender. Not necessarily the border
MTA talking with MXs "elsewhere". This nit can be very
important for SPF, just because you know all your MSAs
doesn't guarantee that you know all your border MTAs -
sometimes I use "mailout" for MSA != "mailout" setups.

> The relay at the recipient's border is called an "MX".

Yes, ignoring the address fallback if there's no MX for
the moment. Short hint for all "terminology" fans here,
the fourth 2822upd draft was just published:

http://tools.ietf.org/html/draft-resnick-2822upd-04

It's discussed on the rfc822 list, there's a new thread
about the terms "originator" and "transmitter", and a
thread about the term "sender" wrt to the header field.

If you want to improve these "official" definitions go
for it NOW, as soon as 2821bis / 2822upd are at "draft
standard" their terminology will stay for some DECADES.

Frank

-------------------------------------------
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=86321779-54cb4c
Powered by Listbox: http://www.listbox.com

Alex van den Bogaerdt wrote:

> Why would there be a difference between:

> "... MX --> Forwarder ==> MX --> Recipient"
> and
> "... MX --> Internal_relay1 --> Internal_relay2 --> Recipient"
> ?

The number of admins (ADMDs) is different. In the 2nd
scenario it's easy to say "you broke it, you fix it" ;-)

-------------------------------------------
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=86323368-34d9a2
Powered by Listbox: http://www.listbox.com

On Wed, Jan 16, 2008 at 04:15:33AM +0100, Frank Ellermann wrote:
> Alex van den Bogaerdt wrote:
>
> > Why would there be a difference between:
>
> > "... MX --> Forwarder ==> MX --> Recipient"
> > and
> > "... MX --> Internal_relay1 --> Internal_relay2 --> Recipient"
> > ?
>
> The number of admins (ADMDs) is different.

To which I say: "so what" ...

> The number of admins (ADMDs) is different. In the 2nd
> scenario it's easy to say "you broke it, you fix it" ;-)

... because I disagree. This is also possible in the first scenario.
In both cases it is the recipient (or his employer, or his ISP, or...)
who screwed up.

The messages was delivered to "MX". That worked.

That is why my message read:

[...]
> Whatever happens to this message is now under control of the recipient,
> and problems occuring from that moment on are the recipient's problems.

> Why would there be a difference between:
[...]

-------------------------------------------
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=86373988-1e5e73
Powered by Listbox: http://www.listbox.com

Alex van den Bogaerdt wrote:

>> The number of admins (ADMDs) is different. In the 2nd
>> scenario it's easy to say "you broke it, you fix it" ;-)

> ... because I disagree. This is also possible in the
> first scenario. In both cases it is the recipient (or
> his employer, or his ISP, or...) who screwed up.

The recipient is an ordinary user, and ordinary users are
IMO entitled to be clueless - well, if they still "surf"
as Windows admin they should get ready for jail time if
that ends as it must end.

The admin of the forwarder is not forced to support SRS,
the admin of the receiver is not forced to white list
the forwarder. They didn't *break* anything that wasn't
already broken by RFC 1123 5.3.6(a). I submitted an
erratum for this RFC, but this wasn't about 5.3.6(a).

2821bis does not acknowledge that RFC 1123 5.3.6(a) was
always broken. I think we differ from 2821bis, but if
forwarders strictly follow 2821bis they only *break*
RFC 821, and everybody knows that RFC 821 isn't up to
date. RFC 4408 claims that RFC 821 reverse routes are
"archaic", an appeal against this wording was rejected.

Unless the IESG decides that 2821bis is too important
to do it outside of a proper IETF WG we'll get what it
says at the moment:

| To expand an alias, the recipient mailer simply
| replaces the pseudo-mailbox address in the envelope
| with each of the expanded addresses in turn; the rest
| of the envelope and the message body are left unchanged.
| The message is then delivered or forwarded to each
| expanded address.

"We" know that this cannot work for the 821-architecture
after 1123 killed the reverse routes, but obviously "we"
didn't manage to convince the author of 2821bis-06 that
this is madness for addresses at 3rd parties (in another
ADMD or MRN, pick what you like best).

Frank

-------------------------------------------
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=86433846-765ed2
Powered by Listbox: http://www.listbox.com

On Wed, Jan 16, 2008 at 04:14:46PM +0100, Frank Ellermann wrote:

> >> The number of admins (ADMDs) is different. In the 2nd
> >> scenario it's easy to say "you broke it, you fix it" ;-)
>
> > ... because I disagree. This is also possible in the
> > first scenario. In both cases it is the recipient (or
> > his employer, or his ISP, or...) who screwed up.
>
> The recipient is an ordinary user, and ordinary users are
> IMO entitled to be clueless

Sure. But that still doesn't make it my problem.

When a receiver uses SPF (knowingly or not) at the wrong place, then
only the receiver can fix it/have it fixed.

I know little about television hardware. That's why I won't build my
own set, nor do I attempt to repair it when it's broken. Should I
electrocute myself when I would open the hood, then that's not the
fault of the manufacturor, the electricity company, the broadcasting
company or anyone else involved. My set, my actions, my problem.

It is the same with computers and the Internet. You have the right to
be clueless. Hire someone who isn't if you need to investigate a problem.

[snip - about alias forwarding, 2821bis and such]

Your reasoning would also mean that if I sent mail through an alias,
such a message should always arrive, even if the final destination
would reject it for other reasons such as DNSBLs, spamassassin scores,
and what more. It doesn't work that way.

If someone chooses to use SPF, be it deliberately or unknowingly, they
are bound by a more restrictive set of rules.


2nd remark about that part of 2821bis: *after* alias expansion, either
delivery or forwarding happens. Now read 3.9, 3.9.1 and 3.9.2 again.

3.9.2 says: "Note that
the key difference between handling aliases (Section 3.9.1) and
forwarding (this subsection) is the change to the backward-pointing
address in this case.
"

3.9 says: "When a message is
delivered or forwarded to each address of an expanded list form, the
return address in the envelope ("MAIL FROM:") MUST be changed to be
the address of a person or other entity who administers the list.
"

Combined with 3.9.1, I read this as:

sales@example.com is an alias
the alias expands to
- user1@example.com
- user@example.com
- user3@other.example
user1@example.com and user2@example.com can be delivered right away, but
for user3@other.example one needs to forward the message. This means
changing the return address.


But I'm sure this is open to interpretation, because that entire part
of the rfc is disagreeing with itself. Example: 3.9.2 says
" operate by "redistribution" rather than
by "forwarding".
"
and then continues by saying "...forwarding (this subsection)...".
So, 3.9.2 is about redistribution rather than forwarding, it is about
forwarding... yeah, clear, so is it or is it not about forwarding ?

Sigh.

-------------------------------------------
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=86452298-41ae24
Powered by Listbox: http://www.listbox.com

At 12:12 AM 1/16/2008 +0100, Alessandro Vesely wrote:
>David MacQuigg wrote:
>>Alessandro Vesely wrote:
>>>I'm not sure aol.com should be labeled "MDA".
>>That is their role in this exchange. Of course, as a company
>>they provide a lot of other services, including Sender,
>>Transmitter, Receiver, Forwarder, Webhost, Domain Registrar,
>>Targeted Advertising ...
>>
>>>In addition, there is a second border after the
>>>Forwarder(s). The latter is what makes it difficult for the
>>>receiver to reuse spam knowledge gathered by the recipient.
>>??? There is a *direct* relationship between the Receiver and
>>the Recipient. The Recipient should send spam reports
>>directly to the Receiver, not AOL, not SpamCop, not anyone
>>who has no *first-hand knowledge* of the source of the spam.
>
>This is where I get lost. We don't actually mount AOL's hard disks on the Receiver host --which I'd call "direct". Formally, we engage an SMTP (or LMTP) transaction with their server, playing the transmitter's role.

Maybe we could show direct relationships with == and indirect relationships with ~~ and "same ADMD" relationships as MTA1/MTA2. The situation we are discussing is then illustrated as:

/ /====================\
Sender(s) ==> Transmitter --> / --> Receiver/Forwarder ~~> MDA ==> Recipient
/
Border (box67.com) (aol.com)

What I mean by a "direct relationship" is a contract, or at least a signup on a website. As an example, my service box67.com acts as a Receiver and Forwarder for an individual, Robert, who has asked us to forward his mail to aol.com. Robert has an account at aol.com, so there is also a direct relationship between him and AOL. Those two direct relationships establish an indirect relationship between box67.com and aol.com, at least for this one Recipient.

As a consequence of this indirect relationship with AOL, in principle, box67.com can say to AOL, "Hey, we are buddies, turn OFF your spam filter, and don't complain about what we send to Robert." AOL may be surprised by that assertion, but after checking with Robert, they should say, "You are right, Robert wants you to forward everything to his mailbox."

The relationship among the Agents in an MRN is very different than between totally unrelated parties on the open Internet. Robert is in charge of this particular MRN, as he is the one who made all the arrangements. As you have noticed, the MRN can change with every message, even to the same Recipient. I have multiple accounts at yahoo.com, and each one has a different set of forwarding arrangements.

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

Alex van den Bogaerdt wrote:

> that entire part of the rfc is disagreeing with itself.

Please post it on the SMTP or the general list, I just
can't add *another* nit at this time, they'd killfile
me if they haven't done yet - I posted the majority of
the 2821bis Last Call comments. That ended 2007-12-24,
I've no excuse for being late in this case... :-(

Or add it to the last active Last Call thread, I copied
parts of what I have written here, and your reply fits.

Frank

-------------------------------------------
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=86769155-1864d6
Powered by Listbox: http://www.listbox.com

On Mon, 14 Jan 2008, Stuart D. Gathman wrote:
> AOL is a poster child for why the canard about how SPF "breaks forwarding"
> is complete FUD. *Any* system that blocks the sources of spam
> "breaks forwarding".

The real problem is that there are at least three separate "Forwarding
Problems":

Forwarding Problem S - To technologies like SPF, traditionally forwarded
messages appear to be forgeries.

Forwarding Problem K - Forwarding source IPs will accumulate "bad karma"
when they innocently pass on spam to a MUA with a "this is spam" button
and a luser operating it.

Forwarding Problem B - Forwarders are left holding a hot potato if they
accept SPF-neutral mail and the ultimate recipient MX 5xx's it.

Problems K and B really hurt the forwarder, and can only be resolved by
recipient whitelisting, period.

Problem S can be resolved by the forwarder alone, but it's in the
forwarder's interest to play dumb, since if the recipient solves Problem S
at his own end, he also solves Problem K, and if the recipient admin is
honourable, problem B as well.

(Once an honourable mail admin *knows* that a given message is a trusted
forward, he must turn off spam defenses so that he doesn't force Problem B
on an innocent other admin. But in the 2007 discussion here, it was
claimed that most admins will dishonourably comply with customer orders to
spamfilter the forwarded mailstream....

Fortunately, the recipient admin has no selfish reason not to fix Problem
K, once he has the information and technology needed to fix Problem S.)

---- Michael Deutschmann <michael@talamasca.ocis.net>

-------------------------------------------
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=86803022-5afb66
Powered by Listbox: http://www.listbox.com

Michael Deutschmann wrote:

> Forwarding Problem B - Forwarders are left holding a hot
> potato if they accept SPF-neutral mail and the ultimate
> recipient MX 5xx's it.

> Problems K and B really hurt the forwarder, and can only
> be resolved by recipient whitelisting, period.

B: I think that's no specific "forwarding" problem, a receiver
accepting NONE / NEUTRAL is in trouble if he can't deliver the
mail. That's why SPF was invented, for FAIL reject works, for
PASS accept works, and for NONE / NEUTRAL it's a hard problem.

> Once an honourable mail admin *knows* that a given message is
> a trusted forward, he must turn off spam defenses so that he
> doesn't force Problem B on an innocent other admin.

That would limit the next hop to the defenses available at the
forwarder, neither "better" nor "different" would be honourable.

The forwarder accepted the mail for some reasons, therefore he
is 100% responsible for it. If he doesn't like that, a valid
decision, he can reject it with "551" as explained in RFC 821.

Taking "251" decisions lightly is a failure of the forwarder -
it can't be the failure of later hops.

Of course "we" urge senders to help out with SPF PASS / FAIL
policies, allowing receivers (or here forwarders) to avoid the
2821bis NONE / NEUTRAL dilemma, but at the end of the day it's
the receiver (here forwarder) who accepted NONE / NEUTRAL mail.

Frank

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

On Thu, 17 Jan 2008, Frank Ellerman wrote:
> B: I think that's no specific "forwarding" problem, a receiver
> accepting NONE / NEUTRAL is in trouble if he can't deliver the
> mail. That's why SPF was invented, for FAIL reject works, for
> PASS accept works, and for NONE / NEUTRAL it's a hard problem.

If a mail system has backup MXes, and is misconfigured so that the
primary MX might 5xx mail from the backup, then something like Problem B
can occur. In fact, this is likely the cause of most backscatter.

To prevent it, the only sensible thing for a sysadmin with backup MXes to
do is to always give the backups carte blanche. Primary MX thinks it's
spam? -- then too bad, once the backup acknowledges CR LF . CR LF it's
*too late*. Mailbox over quota? Then disregard the quota and add the
message to the mailbox anyway.

The common thread among all three forwarding problems is that the
forwarder is a quasi backup MX for the forward-to domain, but usually
isn't recognized as such by that domain.

If the recipient mail admin is ignorant of the forwarder's
quasi-backup-MX status, then he can't really be blamed for Problem B. But
if he gathers the information needed to solve Problem S and Problem K,
then he *knows* which mail transactions are forwards. Since his decision
might bring the wrath of backscatterer.org on the forwarder, it is
dishonourable for him not to extend backup-MX-like superwhitelisting for
those transactions.

> > Once an honourable mail admin *knows* that a given message is
> > a trusted forward, he must turn off spam defenses so that he
> > doesn't force Problem B on an innocent other admin.
>
> That would limit the next hop to the defenses available at the
> forwarder, neither "better" nor "different" would be honourable.

That may annoy the recipient, but it is unavoidable. Once the forwarder
has acknowledged the badguy's CR LF . CR LF it is too late to appeal the
forwarder's judgement. (unless the mail was SPF pass.)

The recipient just has to learn to use the anti-spam "control panel" the
forwarder provides him, even if he finds it less user-friendly or capable
than the one at his home ISP.

---- Michael Deutschmann <michael@talamasca.ocis.net>

-------------------------------------------
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=86849313-77d187
Powered by Listbox: http://www.listbox.com

Michael Deutschmann wrote:

> The common thread among all three forwarding problems is that
> the forwarder is a quasi backup MX for the forward-to domain,
> but usually isn't recognized as such by that domain.

If both sides agree on this interpretation it might work. BUT:

Outsourced backup MXs are not more state of the art when they
cause trouble. Where they are still used they'd reject spam
as long as the primary MX is alive and kicking, and even when
their service is needed (main site down) they'd try to reject
(temporarily) anything that's remotely suspicious, because you
write later, once they accepted a "NEUTRAL" mail it's too late.

AND - for a constellation where you're GMail and I'm some small
site you'd not consider to accept mails for an overquota user
just because it's inconvenient for me if you don't. You also
would not give me any confidential data (existence and status
of a mailbox) of your users just because that would help me to
arrive at better decisions for NEUTRAL mail later forwarded to
you.

If we swap this, I'm still the forwarder, but your're a small
site and I'm GMail, it's not much better. I'm guessing, maybe
GMail and others can be more cooperative than I fear.

> Since his decision might bring the wrath of backscatterer.org
> on the forwarder, it is dishonourable for him not to extend
> backup-MX-like superwhitelisting for those transactions.

GMail like most big providers I know offers POP3 pull, with that
a "honourable forwarder" is not forced to send dubious mails to
them, the big sites can fetch it when they feel like it. This
means of course that what their users don't like ends up in the
trash folders of these users, no chance to reject or report it.

> The recipient just has to learn to use the anti-spam "control
> panel" the forwarder provides him

Well, I think I found where I can enable "reject FAIL" at GMX.

Many users would likely not understand technical descriptions,
and big providers don't try to offer technical descriptions -
it would attract the curiosity of spammers, besides anti-spam
tools change fast, and many users like shiny controls where
they can drag "anti-spam" from 0 to 100 and back again without
the faintest idea what this really does, because it's nowhere
explained.

Frank

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

Michael Deutschmann wrote:
>> > Once an honourable mail admin *knows* that a given message is
>> > a trusted forward, he must turn off spam defenses so that he
>> > doesn't force Problem B on an innocent other admin.
>>
>> That would limit the next hop to the defenses available at the
>> forwarder, neither "better" nor "different" would be honourable.

That's unless defensive policies are shared within a given MRN. E.g.
(quasi) backup MXes may look up the same DNSBLs. However, such kind
of arrangements may conflict with the per-user varying nature of
MRNs, unless the union of all MRNs shares the same settings. Large
ISPs might impose that.

BTW, there is no authority who dares officially endorsing a DNSBL,
AFAIK. Once I've asked for that at a local ISOC meeting and they
laughed compassionately...

> That may annoy the recipient, but it is unavoidable. Once the forwarder
> has acknowledged the badguy's CR LF . CR LF it is too late to appeal the
> forwarder's judgement. (unless the mail was SPF pass.)

A "smart" backup MX really should have some knowledge about what mailboxes
exist on the target, just like a forwarder does. In addition, the hosts
may exchange some transitional information (e.g. overquota) and cache it
for a few hours or until it is revised. Simple anti-spam recipes might
also be shared that way.

> The recipient just has to learn to use the anti-spam "control panel" the
> forwarder provides him, even if he finds it less user-friendly or capable
> than the one at his home ISP.

For more involved content filtering that's unavoidable. Users won't get
the sum of all filters, but just the filter at the border. If they extend
the border, they must put there any required defenses as well.

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

David MacQuigg wrote:
> Maybe we could show direct relationships with == and indirect
> relationships with ~~ and "same ADMD" relationships as
> MTA1/MTA2. The situation we are discussing is then
> illustrated as:
>
> / /====================\
> Sender(s) ==> Transmitter --> / --> Receiver/Forwarder ~~> MDA ==> Recipient
> /
> Border (box67.com) (aol.com)
>
> What I mean by a "direct relationship" is a contract, or at
> least a signup on a website. As an example, my service
> box67.com acts as a Receiver and Forwarder for an individual,
> Robert, who has asked us to forward his mail to aol.com.
> Robert has an account at aol.com, so there is also a direct
> relationship between him and AOL.

Thus, in case Robert's account at AOL provides for local storage
you would have written ~~> MDA/Recipient?

I still have problems with forwarding from MDA. Scripts or
similar means to (conditionally) forward messages are in a
different position w.r.t. the Receiver/Forwarder mainstream.

In facts, we can envisage some special behavior that the
forwarding MTA may accomplish in order to honor any specific
agreement that encompasses forwarding mail. However, a send mail
command issued in a different context may revert to the default
MTA behavior. Or do we mean that the "direct relationship"
should affect _any_ mail exchange from box67 to that Recipient
along that path?

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

At 04:10 AM 1/16/2008 +0100, Frank Ellerman wrote:
>Michael Deutschmann wrote:
>
>> The relay at the sender's border is called a "smarthost".
>
>AFAIK a "smarthost" is what's today also known as "MSA":
>
>A relay knowing what to do with mails going "elsewhere"
>from the POV of the sender. Not necessarily the border
>MTA talking with MXs "elsewhere". This nit can be very
>important for SPF, just because you know all your MSAs
>doesn't guarantee that you know all your border MTAs -
>sometimes I use "mailout" for MSA != "mailout" setups.

-- MSA: Mail Submission Agent. An MTA that interacts directly with
users submitting mail, verifying their identity, providing secure
connections, etc.
-- MX: Mail eXchanger. Any MTA that has an MX record in DNS. The word
eXchanger suggests a bygone era when there was little spam, and MTA
functions were so simple that incoming and outgoing mail were both
handled by the same server.

I've been thinking of the MSA as just a part of the Transmitting Service, since that is where Senders submit their mail, but it can certainly be split out in discussions where that level of detail matters.
/
Sender(s) --> MSA/Transmitter --> / --> Receiver --> Forwarder(s) -->
/
Border

I can't think of any example where the MSA and Transmitter would be in separate ADMDs. Crocker suggested that there was a need for "aggregation and routing" to be handled by a separate service, but I wasn't able to get any clarification of what he meant. I thought routing was handled at the Network Layer by routers, and the Network requires small packets, not aggregation.
-- Network Layer: http://en.wikipedia.org/wiki/Network_layer


>> The relay at the recipient's border is called an "MX".
>
>Yes, ignoring the address fallback if there's no MX for
>the moment.

Also, the definition doesn't fit well with how we are trying to describe the roles of the different Agents/Servers. An MX can be any MTA in our diagram. Even an MSA will have an MX record, if Senders are expected to reach it from a remote location.

-- 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=87169003-67f512
Powered by Listbox: http://www.listbox.com

At 12:05 PM 1/17/2008 +0100, Alessandro Vesely wrote:
>David MacQuigg wrote:
>>Maybe we could show direct relationships with == and indirect relationships with ~~ and "same ADMD" relationships as MTA1/MTA2. The situation we are discussing is then illustrated as:
>> / /====================\
>>Sender(s) ==> Transmitter --> / --> Receiver/Forwarder ~~> MDA ==> Recipient
>> /
>> Border (box67.com) (aol.com)
>>What I mean by a "direct relationship" is a contract, or at least a signup on a website. As an example, my service box67.com acts as a Receiver and Forwarder for an individual, Robert, who has asked us to forward his mail to aol.com. Robert has an account at aol.com, so there is also a direct relationship between him and AOL.
>
>Thus, in case Robert's account at AOL provides for local storage you would have written ~~> MDA/Recipient?

Or maybe ~~> MD Agent ==> MUA/Recipient
-- MUA: Mail User Agent - a program running on a Recipient's personal computer, handling mail submission and retrieval.

The MDA (or MD Agent, if we want to make a distinction between machine-level and administrative-level terms) is normally part of the Mail Handling System, separate from the Recipient, an individual in our discussions so far.

>I still have problems with forwarding from MDA. Scripts or similar means to (conditionally) forward messages are in a different position w.r.t. the Receiver/Forwarder mainstream.
>
>In facts, we can envisage some special behavior that the forwarding MTA may accomplish in order to honor any specific agreement that encompasses forwarding mail. However, a send mail command issued in a different context may revert to the default MTA behavior. Or do we mean that the "direct relationship" should affect _any_ mail exchange from box67 to that Recipient along that path?

At 06:39 AM 1/17/2008 +0100, Frank Ellermann wrote:

>The forwarder accepted the mail for some reasons, therefore he
>is 100% responsible for it. If he doesn't like that, a valid
>decision, he can reject it with "551" as explained in RFC 821.
>
>Taking "251" decisions lightly is a failure of the forwarder -
>it can't be the failure of later hops.
>
>Of course "we" urge senders to help out with SPF PASS / FAIL
>policies, allowing receivers (or here forwarders) to avoid the
>2821bis NONE / NEUTRAL dilemma, but at the end of the day it's
>the receiver (here forwarder) who accepted NONE / NEUTRAL mail.

Every Forwarder will set their own policies, but at box67.com, we don't send DSNs. We reject whatever we can identify as forgery, and anything that is not addressed to a valid Recipient, with a verified forwarding address on our system. Having accepted the mail, we then deliver it either to the Recipient's inbox (reputable senders), or to the Recipient's Quarantine, with an appropriate score from our spam filter. If delivery fails, we suspend the Recipient's account, and notify the Recipient via an alternate address. Only if the Recipient fails to respond in a reasonable time, say 30 days, will we terminate the account and delete the queued message. This is a very rare occurrence, and we don't feel any obligation to notify the sender. Its no different than if the Recipient disappeared, and the messages left in storage at his MDA were deleted.

So far, we haven't had any problem with bounces. We don't send any, and we use SRS to reject any "backscatter" coming our way.

-- 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=87160738-2730cf
Powered by Listbox: http://www.listbox.com

At 06:10 PM 1/16/2008 -0800, Michael Deutschmann wrote:
>On Mon, 14 Jan 2008, Stuart D. Gathman wrote:
>> AOL is a poster child for why the canard about how SPF "breaks forwarding"
>> is complete FUD. *Any* system that blocks the sources of spam
>> "breaks forwarding".
>
>The real problem is that there are at least three separate "Forwarding
>Problems":
>
>Forwarding Problem S - To technologies like SPF, traditionally forwarded
>messages appear to be forgeries.
>
>Forwarding Problem K - Forwarding source IPs will accumulate "bad karma"
>when they innocently pass on spam to a MUA with a "this is spam" button
>and a luser operating it.

-- luser: term used mostly by immature computer geeks to show off their
literary skills and contempt for ordinary (non-geek) users.

I don't like the term "luser", due to the attitude it conveys. The users I know are smart but busy people, some with advanced degrees, but not usually in computer science. Looking at my AOL recipients, I see one is an MD, another is a retired VP from a major retailer. They both seem to like AOL. We will do better by making our technology serve their needs. That may not be as hard as it seems. In this case, I would have an automated procedure for the Forwarder to challenge a spam report. The absent-minded MD could then either confirm that he didn't make a mistake, or just ignore the challenge and the report would be ignored.

>Forwarding Problem B - Forwarders are left holding a hot potato if they
>accept SPF-neutral mail and the ultimate recipient MX 5xx's it.
>
>Problems K and B really hurt the forwarder, and can only be resolved by
>recipient whitelisting, period.
>
>Problem S can be resolved by the forwarder alone, but it's in the
>forwarder's interest to play dumb, since if the recipient solves Problem S
>at his own end, he also solves Problem K, and if the recipient admin is
>honourable, problem B as well.

Nice analysis. It took me a while to understand, however. Here is how I would illustrate with an example.


/ /====================\
/ --> Receiver/Forwarder ~~> MDA ==> Recipient
/
(box67.com) (aol.com)

Box67.com is doing everything it can to be a good Forwarder, including using SRS on its forwarded messages. In fact, it is one of the few forwarders in the world that uses SRS. That solves Problem S, but leaves aol.com thinking that the spam *originated* from box67.com (Problem K).

If the problem is to be resolved by one party alone, it would have to be the MDA, not the Forwarder. Aol.com can see that box67.com has very few spam reports, and those few have been mistakes by the Recipient. Correcting these mistakes may take some work, but it could be done.

That work could be eliminated if we get the other parties involved, and improve the whitelisting procedure for the Recipient. Instead of just a few individual sender addresses, he should be able to whitelist an entire domain. Any mail forwarded by box67.com to that Recipient should bypass all further filtering. Any spam reports on box67.com to aol.com from that Recipient should generate an automatic response "You must first take this domain off your whitelist".

>(Once an honourable mail admin *knows* that a given message is a trusted
>forward, he must turn off spam defenses so that he doesn't force Problem B
>on an innocent other admin. But in the 2007 discussion here, it was
>claimed that most admins will dishonourably comply with customer orders to
>spamfilter the forwarded mailstream....

I don't like the assumption that mail admins are dishonest if they don't do things our way. All that does is generate prejudice against SPF and anyone associated with SPF.

>Fortunately, the recipient admin has no selfish reason not to fix Problem
>K, once he has the information and technology needed to fix Problem S.)

Much better! We can talk about motivations and incentives and real-world economics without insulting anyone. Mail admins right now are not greatly motivated to support SPF. We need to explore the reasons and figure out ways to make SPF more relevant to their *self interest*. (Notice I avoid the word "selfish".)

Seems to me that the big ESPs have sufficient self interest to do their part in making forwarded mail more efficient. It would help their customers, and reduce the burden on their own personnel, if we had a simple universal and automatic procedure for setting up forwarding. What are the requirements of this procedure? I can think of the following, maybe you can add some others.:
1) No cost to anyone, other than a small administrative burden.
2) Minimum involvement of the Recipient in error-prone details.
3) No vulnerability to spammers.
If we can design a system that meets these requirements, I believe we will solve the "forwarding problem".

On item 1, adding a simple DNS record would be OK. Installing SRS would be too much to expect, unless we can make it easily installed on all the popular MTAs. Individual attention to every forwarder's request would be too much, especially since we can expect a lot of requests from spammers. The Recipient can provide the necessary approval.

On item 2, we shouldn't expect the Recipient to properly coordinate the arrangements between the Forwarder and the MDA. The Recipient should set up forwarding using whatever procedure the Forwarder expects. Then the Forwarder should communicate with the MDA, and the MDA should ask only a Yes/No from the Recipient.

On item 3, we need robust authentication (PASS or FAIL, no NEUTRAL) on the connection between the Forwarder and the MDA.

-- 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=87160799-6b671c
Powered by Listbox: http://www.listbox.com

On Thu, 17 Jan 2008, David MacQuigg wrote:
> I don't like the term "luser", due to the attitude it conveys. The

I added the "l" since in this case the user's ignorance is pivotal. A
clued-in user knows that flagging forwarded spam will have no effect on
the S/N ratio of the forwarded mailstream, although it might kill the
stream entirely.

Then again, even with clued-in users, it's best if the MUA greys out the
"This is Spam" button for forwarded mail, since the user might fail to
notice that a particular spam was forwarded.

> needs. That may not be as hard as it seems. In this case, I would have
> an automated procedure for the Forwarder to challenge a spam report. The
> absent-minded MD could then either confirm that he didn't make a mistake,
> or just ignore the challenge and the report would be ignored.

I don't think that would work. If the default action, once a sender
claims to be a forwarder, is to cancel the complaint spammers would appeal
everything and hope the users are too lazy to re-confirm.

More importantly, an ignorant user just wants mail like the one he marked
to stop coming. For him the forwarding is an irrelevancy, so he'll just
reconfirm the complaint and we are back at square one.

Your solution is rather blue-sky. If we're talking blue-sky solutions,
it would be better to add a system to channel "This is spam" feedback back
to the forwarder, so that the forwarder can use the data for it's *own*
filter/blacklist training and the user doesn't need to worry over the
difference.

But a "forwarding problem solution" that tried to do that would be too
complicated to implement all at once. To reach that heaven, we need to
gradually build up a tower of protocols, each terrace offering a small
improvement for a small amount of work.

* Level 0: Status quo, people are afraid to use receiverside SPF.

* Level 1: TENBOX/E. Forwarder whitelisting is possible for power users.
The recipient asks his mail admin to whitelist mail bearing the SWK for
the forwarding relationship.

* Level 2: As Level 1, but a protocol is added to allow the Forwarder to
enquire as to whether his SWK is truly whitelisted by a given recipient
mailbox, allowing some idiot-proofing.

* Level 3: TENBOX/O. A means is provided for the forwarder to identify a
special mailbox to send automated requests for whitelisting. On receiving
a request, a TENBOX/O supporting ISP will then internally generate a
confirmation message and add the SWK to a whitelist if the recipient
confirms.

* Level 4: Means are added to allow the forwarder to collect "This is
Spam" results from the mails it has sent in the past.

> I don't like the assumption that mail admins are dishonest if they
> don't do things our way.

Honesty has nothing to do with it -- no lying is involved. But allowing
Problem B remains a Golden Rule violation.

If the recipient thinks it is OK to risk backscatter, he should tell the
forwarder to use the original MAIL FROM:, specify that SPF checking is to
be disabled for mail identified as a forward, and that any rejections from
his local spamfilter are to cause post-transaction bounces, not
in-transaction rejections.

Most people would say the above solution is very irresponsible, although
there is no less destructive way to guarantee that (non-forged) false
positives will be reported to the original sender. But in-transaction
rejection of a forwarded mail is even worse, because it additionally
displaces the punishments for this behavior onto someone else's MTA.

> All that does is generate prejudice against SPF and anyone associated
> with SPF.

My viewpoint is not the standard SPF one. The standard SPF viewpoint
(which I joined the list to fight) seems to be that forwarders should
solve Problem S themselves with SRS and just suck up Problems B and K.

---- Michael Deutschmann <michael@talamasca.ocis.net>

-------------------------------------------
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=87357862-3af976
Powered by Listbox: http://www.listbox.com

On Fri, 18 Jan 2008, Michael Deutschmann wrote:

> My viewpoint is not the standard SPF one. The standard SPF viewpoint
> (which I joined the list to fight) seems to be that forwarders should
> solve Problem S themselves with SRS and just suck up Problems B and K.

The standard SPF viewpoint is that forwarding is requested by the
receiver, and is the responsibility of the receiver. SRS doesn't
solve any forwarding problems - it just makes whitelisting (or otherwise
identifying forwarded mail from) the forwarder easier. Which only helps if the
recipient does whitelist (or doesn't track reputation - effectively
whitelisting everyone). Forwarding problems are problems with
receiver policy, not sender policies. A forwarder is acting as an
agent of the receiver - but is often not given the information or
standing by the receiver to carry out their function effectively.

What this discussion is highlighting is not a problem with Sender Policies,
but the need for some *receiver* policies to be propagated to forwarders in an
automatic fashion. For instance, if AOL made their ip blacklist available
by DNS, it would help forwarders avoid forwarding mail AOL users don't
like. (Though would likely cause other problems.)

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
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=87504306-3ea70f
Powered by Listbox: http://www.listbox.com

Michael Deutschmann wrote:
> But a "forwarding problem solution" that tried to do that would be too
> complicated to implement all at once. To reach that heaven, we need to
> gradually build up a tower of protocols, each terrace offering a small
> improvement for a small amount of work.
>
> * Level 0: Status quo, people are afraid to use receiverside SPF.

I'd also mention they are afraid to use backup MXes. After Frank said "it
might work", I'd like to try and solve both problems at once, for we may
gather more consensus that way.

> * Level 1: TENBOX/E. Forwarder whitelisting is possible for power users.
> The recipient asks his mail admin to whitelist mail bearing the SWK for
> the forwarding relationship.

L1 implies the forwarder can authenticate itself, or the MTA has been
patched in order to implement TENBOX/E, or I haven't grasped TENBOX/E
quite enough. :-)

Shouldn't we "just" provide an rfc 1425 SMTP extension for forwarding?

> * Level 2: As Level 1, but a protocol is added to allow the Forwarder to
> enquire as to whether his SWK is truly whitelisted by a given recipient
> mailbox, allowing some idiot-proofing.

What's wrong with just checking the response to "MAIL FROM:<> AUTH=<swk>"
or whatever TENBOX/E will prescribe?

> * Level 3: TENBOX/O. A means is provided for the forwarder to identify a
> special mailbox to send automated requests for whitelisting. On receiving
> a request, a TENBOX/O supporting ISP will then internally generate a
> confirmation message and add the SWK to a whitelist if the recipient
> confirms.

Fine.

> * Level 4: Means are added to allow the forwarder to collect "This is
> Spam" results from the mails it has sent in the past.

Fine. L3 and L4 don't really have to come in that order. Actually, L4
seems more urgent to me...

-------------------------------------------
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=87513558-31b126
Powered by Listbox: http://www.listbox.com

David MacQuigg wrote:
> At 12:05 PM 1/17/2008 +0100, Alessandro Vesely wrote:
>> David MacQuigg wrote:
>>> Maybe we could show direct relationships with == and
>>> indirect relationships with ~~ and "same ADMD"
>>> relationships as MTA1/MTA2. The situation we are
>>> discussing is then illustrated as:
>>> / /====================\
>>> Sender(s) ==> Transmitter --> / --> Receiver/Forwarder ~~> MDA ==> Recipient
>>> /
>>> Border (box67.com) (aol.com)
>>>
>>
>> Thus, in case Robert's account at AOL provides for local
>> storage you would have written ~~> MDA/Recipient?
>
> Or maybe ~~> MD Agent ==> MUA/Recipient -- MUA: Mail User
> Agent - a program running on a Recipient's personal computer,
> handling mail submission and retrieval.
>
> [...]
> Recipient, an individual in our discussions so far.

Ooops, you're right. I was thinking about his mail folders.

somewhere else you wrote:
> Any mail forwarded by box67.com to that Recipient should
> bypass all further filtering.

What if you relay (rather than forward) a message to Robert from
box67.com, using it as an outgoing mail server? Will the
extended trust still be operative in that case?

-------------------------------------------
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=87561011-8f62f8
Powered by Listbox: http://www.listbox.com

On Fri, 18 Jan 2008, Alessandro Vesely wrote:
> Michael Deutschmann wrote:
> > * Level 0: Status quo, people are afraid to use receiverside SPF.
>
> I'd also mention they are afraid to use backup MXes. After Frank said "it

Backup MXs need the same super-whitelisting as forwarders. But TENBOX
isn't needed, since they can be easily granted that whitelisting based on
IP address or conventional SMTP-AUTH usage.

If your talking a "TENBOX/U" protocol (U for United front) which would
allow spam policies on the forwarder to be kept in perfect sync with the
primary -- I can see that it would be very useful for Backup MX
administration but this would be near-impossible to pull off in a general
way.

> > * Level 1: TENBOX/E. Forwarder whitelisting is possible for power users.
>
> L1 implies the forwarder can authenticate itself, or the MTA has been
> patched in order to implement TENBOX/E, or I haven't grasped TENBOX/E
> quite enough. :-)
That's why this has it's own level. Each level requires new software
at the forwarder and the ultimate recipient.

> Shouldn't we "just" provide an rfc 1425 SMTP extension for forwarding?
I'm going for a pseudo-SASL mechanism rather than an ESMTP keyword,
because much more RFC-lawyering is needed to register the latter.

> > * Level 2: As Level 1, but a protocol is added to allow the Forwarder to
>
> What's wrong with just checking the response to "MAIL FROM:<> AUTH=<swk>"
> or whatever TENBOX/E will prescribe?

Just because a message gets through doesn't mean the sender was
whitelisted. And a probe that doesn't go to DATA tells you nothing about
content filters, or the presence of an armed "This is spam" button.

(The TENBOX/E spec I posted earlier did define a special method. If the
MAIL FROM is in the @invalid domain, the MTA is to 5xx the RCPT TO if full
whitelisting is not present for the SWK/recipient pair.)

---- Michael Deutschmann <michael@talamasca.ocis.net>

-------------------------------------------
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=87764946-498ecd
Powered by Listbox: http://www.listbox.com

Michael Deutschmann wrote:
> If your talking a "TENBOX/U" protocol (U for United front) which would
> allow spam policies on the forwarder to be kept in perfect sync with the
> primary -- I can see that it would be very useful for Backup MX
> administration but this would be near-impossible to pull off in a general
> way.

Content filtering requires specialized software and large data bases.
Thus, it's natural for each host to provide its own. For example,
anti-virus scanning probably occurs at each hop.

OTOH, protocol-based techniques, such as DNSBL lookups, greylisting,
SPF, SRS vs. non-disclosure that an address is actually an alias, et
cetera, can be described within a few bytes of configuration details
that the primary host may supply. Of course, we need a register where
those techniques are enumerated... it is incredible that an official
one doesn't exist already. The taxonomy that Frank mentioned is in
http://wiki.asrg.sp.am/index.php/Taxonomy_of_anti-spam_techniques

While a target host may have uniform spam policies for all recipients,
a forwarder must be able to dynamically adapt its behavior depending
on the recipient. That may result in a not so simple algorithm when
the same message with multiple recipients has to undergo different
policies, but it is perfectly feasible.

The U-protocol could boil down to specifying the format of a file that
forwarders must keep rsynced with any host they forward to. A list of
(allowed) recipients should also be downloaded, specially for backup
MXes -- forwarders may be notified of an account termination that way,
overquota information may be attached.


Let me note down a few loose ends:

* U-protocol specs that cannot be configured automatically, e.g. because
a DNSBL requires a payment or the software is not capable, should result
in 4xx or 511 responses before even entering the forwarding phase.

* Deciding to forward at a later stage, e.g. after a script detects
some specific header or content in the message, should be a different
kind of forwarding. Perhaps it should mime-wrap the message, much
like MUA-forwarding does, or use those "Resent-" headers.

* In what cases a forwarder should _not_ replace the envelope sender
address?

* How does the primary host make sure its policies have been obeyed?
A malicious forwarder could, say, pretend it did DNSBL lookup and
write a fake Received.

-------------------------------------------
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=87770280-6175ec
Powered by Listbox: http://www.listbox.com

At 07:57 PM 1/18/2008 +0100, Alessandro Vesely wrote:
>David MacQuigg wrote:
>
>>Any mail forwarded by box67.com to that Recipient should
>>bypass all further filtering.
>
>What if you relay (rather than forward) a message to Robert from box67.com, using it as an outgoing mail server? Will the extended trust still be operative in that case?

Box67.com does not "relay" anything to unrelated parties. All forwarding is done with prior arrangement.

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

On Sat, 19 Jan 2008, David MacQuigg wrote:

> Box67.com does not "relay" anything to unrelated parties. All forwarding is
> done with prior arrangement.

That is called "relay". Open relays were banned over a decade ago.
All relays are now via prior arrangement.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------------------------------------------
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=88192944-9a5709
Powered by Listbox: http://www.listbox.com

Restoring the previous context:
>At 07:57 PM 1/18/2008 +0100, Alessandro Vesely wrote:
>>David MacQuigg wrote:
>>
>>>Any mail forwarded by box67.com to that Recipient should
>>>bypass all further filtering.
>>
>>What if you relay (rather than forward) a message to Robert from box67.com, using it as an outgoing mail server? Will the extended trust still be operative in that case?
>
>Box67.com does not "relay" anything to unrelated parties. All forwarding is done with prior arrangement.


At 12:11 PM 1/21/2008 -0500, Stuart wrote:
>On Sat, 19 Jan 2008, David MacQuigg wrote:
>
>> Box67.com does not "relay" anything to unrelated parties. All forwarding is
>> done with prior arrangement.
>
>That is called "relay". Open relays were banned over a decade ago.
>All relays are now via prior arrangement.

There seems to be some of confusion (disagreement?) over the term "relay", so I'm trying to avoid it (other than in quotes as above). Crocker has a definition, but it seems to be limited to just one machine or process, and we need to discuss things at the "administrative" level. Also, Crocker does not recognize the presence of a Border, so his "relays" can be anywhere.

Instead of "relay", I suggest we use the terms Transmitter and Forwarder to describe two roles that look the same at the "machine" level, but are very different in their administrative requirements.

Box67.com is a single Agent playing two roles (Receiver and Forwarder) and running multiple processes. It never plays the role of Transmitter. Except for a few admin accounts, it doesn't play the role of Mail Distribution Agent (MDA) either.

|----------- MON -----------| |----------------- MRN ----------------|
/
Sender(s) ==> MSA/Transmitter --> / --> Receiver/Forwarder ~~> MDA ==> Recipient
/
Border

--> Direction of mail flow (no relationship implied)
==> Direct relationship (e.g. a contract)
~~> Indirect relationship (e.g. both directly related to Recipient)

-- 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=88341702-0e0433
Powered by Listbox: http://www.listbox.com