Mailing List Archive

Statement of Problems and Requirements (Last Call)
Since the discussion of solutions and implementation details seems to be full-speed forward, I would like to wrap up the earlier steps. Here is what I have at http://open-mail.org/Forwarding.html. The only thing new is Problem R. This goes well beyond the specifics of forwarding, but I thought it would be good to include in our list. In devising a solution to the Forwarding Problem, we should do our best to have it solve the larger problem as well.

Statement of Forwarding Problems

Problem S - To technologies like SPF, messages forwarded without re-writing the Return Address appear to be forgeries.

Problem K - Forwarders will accumulate "bad karma" when they innocently pass on spam to a downstream Agent without prior arrangement, or with arrangements that are mistakenly ignored.

Problem B - Mail may be lost when a Receiver accepts a message without authenticating the Return Address and a downstream Agent rejects it.

(still needing discussion):

Problem P - Recipients have difficulty keeping track of and updating their forwarding arrangements.

Problem R - The reliability of the global email system is so bad that users cannot be confident of delivery unless there is prior arrangement between Agents at the Border of the sending and receiving networks.

Requirements for Solution to Forwarding Problems

1) No cost or risk to Agents on Sender's side
2) Small cost or risk to Agents on Recipient's side
3) No lost mail
4) Effective
5) Minimum vulnerability to new attacks
6) At every stage of adoption, benefits must exceed costs to each Agent
that must take some action.

(still needing discussion):

7) Forwarder authentication must be resolved before the DATA command.


Possible Solutions

see http://open-mail.org/Forwarding.html Have I forgotten anything?

-- 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=94615371-eebf41
Powered by Listbox: http://www.listbox.com
Re: Statement of Problems and Requirements (Last Call) [ In reply to ]
Dave,

Once again, thanks for the good work. I think that it might make
sense to create an illustrative example for each of the Statement of
Forwarding Problems. That way, the problem becomes clear for a
casual observer and will further clarify where certain problems are
seen by way of example.

Best,

AlanM
The Commerce Company
TZ.Com - Travel Zippy

At 05:56 PM 2/6/2008, you wrote:
>Since the discussion of solutions and implementation details seems
>to be full-speed forward, I would like to wrap up the earlier
>steps. Here is what I have at
>http://open-mail.org/Forwarding.html. The only thing new is Problem
>R. This goes well beyond the specifics of forwarding, but I
>thought it would be good to include in our list. In devising a
>solution to the Forwarding Problem, we should do our best to have it
>solve the larger problem as well.
>
>Statement of Forwarding Problems
>
>Problem S - To technologies like SPF, messages forwarded without
>re-writing the Return Address appear to be forgeries.
>
>Problem K - Forwarders will accumulate "bad karma" when they
>innocently pass on spam to a downstream Agent without prior
>arrangement, or with arrangements that are mistakenly ignored.
>
>Problem B - Mail may be lost when a Receiver accepts a message
>without authenticating the Return Address and a downstream Agent rejects it.
>
>(still needing discussion):
>
>Problem P - Recipients have difficulty keeping track of and updating
>their forwarding arrangements.
>
>Problem R - The reliability of the global email system is so bad
>that users cannot be confident of delivery unless there is prior
>arrangement between Agents at the Border of the sending and receiving networks.
>
>Requirements for Solution to Forwarding Problems
>
>1) No cost or risk to Agents on Sender's side
>2) Small cost or risk to Agents on Recipient's side
>3) No lost mail
>4) Effective
>5) Minimum vulnerability to new attacks
>6) At every stage of adoption, benefits must exceed costs to each Agent
> that must take some action.
>
>(still needing discussion):
>
>7) Forwarder authentication must be resolved before the DATA command.
>
>
>Possible Solutions
>
>see http://open-mail.org/Forwarding.html Have I forgotten anything?
>
>-- 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/?&
>Powered by Listbox: http://www.listbox.com


-------------------------------------------
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=94726930-8804d0
Powered by Listbox: http://www.listbox.com
Re: Statement of Problems and Requirements (Last Call) [ In reply to ]
Are we calling forwarders, forwarders yet or are you still changing existing
terminology?

Scott K

-------------------------------------------
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=94751093-0c8769
Powered by Listbox: http://www.listbox.com
Re: Statement of Problems and Requirements (Last Call) [ In reply to ]
Scott Kitterman wrote:
> Are we calling forwarders, forwarders yet or are you still changing existing
> terminology?

What is the difference? Changes to the terminology may make definitions
more accurate, but should never conflict with the correct usage of the terms.

The current glossary definition is "a relay performing alias expansion,
i.e. replacing the envelope RCPT address with preconfigured values" (see
http://www.openspf.org/Community/Glossary )

-------------------------------------------
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=94772518-c1e5af
Powered by Listbox: http://www.listbox.com
Re: Statement of Problems and Requirements (Last Call) [ In reply to ]
At 09:15 PM 2/6/2008 -0700, AlanM wrote:

>I think that it might make sense to create an illustrative example for each of the Statement of Forwarding Problems. That way, the problem becomes clear for a casual observer and will further clarify where certain problems are seen by way of example.

Good suggestion. Here is a first draft. Clarifications and additional examples are welcome.

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

Problem S - To technologies like SPF, messages forwarded without re-writing the Return Address appear to be forgeries.
A message from tom@sender.com is sent to dave@forwarder.org, where it is forwarded to dave@mda.net, keeping the original Return Address, tom@sender.com. mda.net sees that the SPF record of sender.com ends in -all and does not include the IP address of forwarder.org. The message is rejected by mda.net due to what looks like forgery of the Return Address by forwarder.org.
Problem K - Forwarders will accumulate "bad karma" when they innocently pass on spam to a downstream Agent without prior arrangement, or with arrangements that are mistakenly ignored.
Recipient Dave forgot to turn OFF spam filtering at mda.net. Spam that got past the filter at forwarder.org is forwarded as requested to dave@mda.net. mda.net reports forwarder.org to SpamCop.
Problem B - Mail may be lost when a Receiver accepts a message without authenticating the Return Address and a downstream Agent rejects it.
Forwarder.org accepts a message for Dave, but then finds that the forwarding address dave@mda.net is no longer in service. There is no SPF record for sender.com, the domain in the Return Address, so forwarder.org cannot safely send a non-delivery notice. Forwarder.org then discards the message, with no notice to either Sender or Recipient.
Problem P - Recipients have difficulty keeping track of and updating their forwarding arrangements.
Maybe Ale can provide a good example here.
Problem R - The reliability of the global email system is so bad that users cannot be confident of delivery unless there is prior arrangement between Agents at the Border of the sending and receiving networks.
Numerous instances of lost mail have led many users to conclude that email is not to be trusted for important communications. Large ESPs like yahoo.com maintain lists of reputable senders, and insist that small senders fill out an application to be included on the list. Otherwise their mail, regardless of content, will be delivered to a quarantine folder and possibly lost in the spam.
Small companies are finding that they can no longer operate their own mail servers in this environment, but must sign up with one of the larger ESPs or anti-spam services. They just don't have the resources to get on everyone's list, or maintain a list of their own.
-- 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=92535246-d152ac
Powered by Listbox: http://www.listbox.com
Re: Statement of Problems and Requirements (Last Call) [ In reply to ]
Looks like the mailing list deletes spaces and destroys formatting. I guess that disk space is really costly! :>(

Let's try again with two levels of quote on the "indented" paragraphs.

At 09:15 PM 2/6/2008 -0700, AlanM wrote:

>I think that it might make sense to create an illustrative example for each of the Statement of Forwarding Problems. That way, the problem becomes clear for a casual observer and will further clarify where certain problems are seen by way of example.

Good suggestion. Here is a first draft. Clarifications and additional examples are welcome.

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

Problem S - To technologies like SPF, messages forwarded without re-writing the Return Address appear to be forgeries.

>>A message from tom@sender.com is sent to dave@forwarder.org, where it is forwarded to dave@mda.net, keeping the original Return Address, tom@sender.com. mda.net sees that the SPF record of sender.com ends in -all and does not include the IP address of forwarder.org. The message is rejected by mda.net due to what looks like forgery of the Return Address by forwarder.org.

Problem K - Forwarders will accumulate "bad karma" when they innocently pass on spam to a downstream Agent without prior arrangement, or with arrangements that are mistakenly ignored.

>>Recipient Dave forgot to turn OFF spam filtering at mda.net. Spam that got past the filter at forwarder.org is forwarded as requested to dave@mda.net. mda.net reports forwarder.org to SpamCop.

Problem B - Mail may be lost when a Receiver accepts a message without authenticating the Return Address and a downstream Agent rejects it.

>>Forwarder.org accepts a message for Dave, but then finds that the forwarding address dave@mda.net is no longer in service. There is no SPF record for sender.com, the domain in the Return Address, so forwarder.org cannot safely send a non-delivery notice. Forwarder.org then discards the message, with no notice to either Sender or Recipient.

Problem P - Recipients have difficulty keeping track of and updating their forwarding arrangements.

>>Maybe Ale can provide a good example here.

Problem R - The reliability of the global email system is so bad that users cannot be confident of delivery unless there is prior arrangement between Agents at the Border of the sending and receiving networks.

>>Numerous instances of lost mail have led many users to conclude that email is not to be trusted for important communications. Large ESPs like yahoo.com maintain lists of reputable senders, and insist that small senders fill out an application to be included on the list. Otherwise their mail, regardless of content, will be delivered to a quarantine folder and possibly lost in the spam.
>>
>>Small companies are finding that they can no longer operate their own mail servers in this environment, but must sign up with one of the larger ESPs or anti-spam services. They just don't have the resources to get on everyone's list, or maintain a list of their own.

-- 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=92535246-d152ac
Powered by Listbox: http://www.listbox.com
Re: Statement of Problems and Requirements (Last Call) [ In reply to ]
David MacQuigg wrote:
> Recipient. Problem P - Recipients have difficulty keeping track of and
> updating their forwarding arrangements. Maybe Ale can provide a good
> example here.

The best example I have thus far is the one I wrote last 1st feb:

A former employee wants to delete a forwarding recipe that has been
manually configured years ago, when she left, as a favor to her. Does she
have to get in touch with her former boss? What if she doesn't want him to
know her current email address?

Notice that the former employee probably has no access to her old
company's mail management web form, if any exist, because she is no longer
an employee. I think that example illustrates well why the privacy
requirement is reasonable: the company should allow the relevant data
subjects to remotely manage their forwarding recipes.

I added definitions for some of the above terms in
http://www.openspf.org/Community/Glossary

-------------------------------------------
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=92987559-ab9edd
Powered by Listbox: http://www.listbox.com
Re: Statement of Problems and Requirements (Last Call) [ In reply to ]
At 11:59 PM 2/6/2008 -0500, Scott K wrote:

>Are we calling forwarders, forwarders yet or are you still changing existing
>terminology?

I put the following at the top of the page at http://open-mail.org/MHSmodel.html
'''
The terminology proposed here differs from <http://ece.arizona.edu/%7Eedatools/home/email/Email_Authentication.htm>common usage in that we are making a distinction between "Forwarding" and other kinds of relaying. Here a "Forwarder" is an Agent working on the Recipient's side of the Border. Agents on the Sender's side may be called "Transmitters", or just Sender's relays.

See <http://open-mail.org/Forwarding.html>Forwarding for more discussion of typical problems in Mail Handling Systems.
See <http://tools.ietf.org/html/draft-crocker-email-arch-09>Internet Mail Architecture and this <http://openspf.org/Community/Glossary>glossary for more general terminology.
'''

We should also make it clear in any discussion with someone outside the SPF community, that we are using the term "forwarding" in a more limited way than they might understand. This will avoid problems when we say things like "all forwarders should re-write the Return Address", and they think we are talking about a Transmitter.

-- 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=93031439-502957
Powered by Listbox: http://www.listbox.com
Re: Statement of Problems and Requirements (Last Call) [ In reply to ]
On Saturday 09 February 2008 13:41, David MacQuigg wrote:
> At 11:59 PM 2/6/2008 -0500, Scott K wrote:
> >Are we calling forwarders, forwarders yet or are you still changing
> > existing terminology?
>
> I put the following at the top of the page at
> http://open-mail.org/MHSmodel.html '''
> The terminology proposed here differs from
> <http://ece.arizona.edu/%7Eedatools/home/email/Email_Authentication.htm>com
>mon usage in that we are making a distinction between "Forwarding" and other
> kinds of relaying. Here a "Forwarder" is an Agent working on the
> Recipient's side of the Border. Agents on the Sender's side may be called
> "Transmitters", or just Sender's relays.
>
> See <http://open-mail.org/Forwarding.html>Forwarding for more discussion of
> typical problems in Mail Handling Systems. See
> <http://tools.ietf.org/html/draft-crocker-email-arch-09>Internet Mail
> Architecture and this <http://openspf.org/Community/Glossary>glossary for
> more general terminology. '''
>
> We should also make it clear in any discussion with someone outside the SPF
> community, that we are using the term "forwarding" in a more limited way
> than they might understand. This will avoid problems when we say things
> like "all forwarders should re-write the Return Address", and they think we
> are talking about a Transmitter.

Any approach that takes the view "We are using words you are used to, but to
mean different things." is doomed to fail. Looking back, it was the new term
for open relay I objected to before.

Where there is existing, understood terminology use it. If you need to add an
additional disctinction, add it, don't change it (e.g. open-relay operator
more clearly means what I think whatever it was I complained about last
time). If you can't do that, then make up an entirely different term. Don't
try and overload existing ones.

Scott K

-------------------------------------------
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=93031439-502957
Powered by Listbox: http://www.listbox.com
Re: Statement of Problems and Requirements (Last Call) [ In reply to ]
Scott,

At 12:33 PM 2/9/2008, you wrote:
>On Saturday 09 February 2008 13:41, David MacQuigg wrote:
> > At 11:59 PM 2/6/2008 -0500, Scott K wrote:
> > >Are we calling forwarders, forwarders yet or are you still changing
> > > existing terminology?
.. snip ..
> >
> > We should also make it clear in any discussion with someone outside the SPF
> > community, that we are using the term "forwarding" in a more limited way
> > than they might understand. This will avoid problems when we say things
> > like "all forwarders should re-write the Return Address", and they think we
> > are talking about a Transmitter.
>
>Any approach that takes the view "We are using words you are used to, but to
>mean different things." is doomed to fail. Looking back, it was the new term
>for open relay I objected to before.

I appreciate the spirit of your statement and tend to agree with it,
but I don't think that is what Dave is doing or talking about here.

He appears to want to take the broad term "open relay" and subset the
group of acceptable forwarders to separate what some argue are the
good purposes of an "open relay" in order to cement definitions that
we can work with as a group which focus on specific problems that can
then be addressed with a common lexicon for discussion.

For that I'm quite open to see this process run its course. As I
watch this progress, I get the feeling we are zeroing in on both the
issues that create objections to SPF by some and possibly might get
to some acceptable answers which apply to the potential SPF adopters
out there who have concerns regarding the still vague or non-existent
answers to these questions.

If we can take and address the questions that are left hanging out
there by some to create FUD (fear, uncertainty and doubt) about SPF
and answer them acceptably to the vast majority of those who may
still have concerns based upon the FUD out there, then perhaps we get
more SPF adopters.

This seems a simple and fairly direct approach to problem solving and
so I think it appropriate to give Dave the opportunity to let this
process play out.

After we have gone through the process, we can revisit the
terminology, if needed.


>Where there is existing, understood terminology use it. If you need
>to add an
>additional disctinction, add it, don't change it (e.g. open-relay operator
>more clearly means what I think whatever it was I complained about last
>time). If you can't do that, then make up an entirely different term. Don't
>try and overload existing ones.
>
>Scott K

Best,

AlanM
The Commerce Company
TZ.Com - Travel Zippy


-------------------------------------------
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=93127865-92ca6f
Powered by Listbox: http://www.listbox.com
Re: Statement of Problems and Requirements (Last Call) [ In reply to ]
On Saturday 09 February 2008 15:29, WebMaster@commerco.net wrote:
> Scott,
>
> At 12:33 PM 2/9/2008, you wrote:
> >On Saturday 09 February 2008 13:41, David MacQuigg wrote:
> > > At 11:59 PM 2/6/2008 -0500, Scott K wrote:
> > > >Are we calling forwarders, forwarders yet or are you still changing
> > > > existing terminology?
>
> .. snip ..
>
> > > We should also make it clear in any discussion with someone outside the
> > > SPF community, that we are using the term "forwarding" in a more
> > > limited way than they might understand. This will avoid problems when
> > > we say things like "all forwarders should re-write the Return Address",
> > > and they think we are talking about a Transmitter.
> >
> >Any approach that takes the view "We are using words you are used to, but
> > to mean different things." is doomed to fail. Looking back, it was the
> > new term for open relay I objected to before.
>
> I appreciate the spirit of your statement and tend to agree with it,
> but I don't think that is what Dave is doing or talking about here.

So far every time I read these suggestions I find words are meant to mean
something other than what I think they mean.

> He appears to want to take the broad term "open relay" and subset the
> group of acceptable forwarders to separate what some argue are the
> good purposes of an "open relay" in order to cement definitions that
> we can work with as a group which focus on specific problems that can
> then be addressed with a common lexicon for discussion.

There is a clear distinction between relaying and forwarding (rcpt to doesn't
change in relaying). Trying to conflate them just adds to the confusion.

> For that I'm quite open to see this process run its course. As I
> watch this progress, I get the feeling we are zeroing in on both the
> issues that create objections to SPF by some and possibly might get
> to some acceptable answers which apply to the potential SPF adopters
> out there who have concerns regarding the still vague or non-existent
> answers to these questions.

It's impossible for me to tell without clear language. I get very nervous
about threads entitled last call when the language isn't at all clear.

> If we can take and address the questions that are left hanging out
> there by some to create FUD (fear, uncertainty and doubt) about SPF
> and answer them acceptably to the vast majority of those who may
> still have concerns based upon the FUD out there, then perhaps we get
> more SPF adopters.
>
> This seems a simple and fairly direct approach to problem solving and
> so I think it appropriate to give Dave the opportunity to let this
> process play out.
>
> After we have gone through the process, we can revisit the
> terminology, if needed.

I take the opposite view. Any solution written in inpentetrable jargon that
no one outside the group of jargon developers can understand is no solution
at all.

So, from a last call perspective, thumbs down from me.

Scott K

-------------------------------------------
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=93127865-92ca6f
Powered by Listbox: http://www.listbox.com
Re: Statement of Problems and Requirements (Last Call) [ In reply to ]
On Wed, 6 Feb 2008, David MacQuigg wrote:
> Problem P - Recipients have difficulty keeping track of and updating
> their forwarding arrangements.

These aren't like the three forwarding problems I've laid out.

Problem P is a root cause of my three problems, but is not a forwarding
problem in and of itself.

It's not even THE root cause -- it shares credit with recipient
indifference to the other forwarding problems.

If:

* legitimate mail from <sarah@example.com> to <fred@example.org> is
forwarded to <ralph@example.net>, run through SpamAssassin by example.net
and then delivered to Ralph's mailbox.

* false-postive mail from <sarah@example.com> to <fred@example.org> will
be bounced to <sarah@example.com> when Example.net 5xxs example.orgs
the attempt to forward to Ralph.

* actual spam, forged in <sarah@example.com>'s name and sent to
<fred@example.org>, will also be bounced to <sarah@example.com> when
Example.net 5xxed it.

...then Forwarding Problem B is active. But Ralph doesn't mind. If his
spam-filter triggers, he doesn't worry because he knows the original
sender will know from the bounce that the mail wasn't delivered, and if it
was indeed spam, he never had to acknowledge seeing it.

Sarah will be angry about the backscatter, and will sic the Lumber Cartel
(TINLC) on Example.org, but Ralph *doesn't care about that*.

The only way Ralph will care is if Example.org *deliberately* breaks his
forwarding to punish him.

> Problem R - The reliability of the global email system is so bad that
> users cannot be confident of delivery unless there is prior arrangement
> between Agents at the Border of the sending and receiving networks.

This isn't specific to forwarding, and doesn't even apply very strongly
to forwarding.

Forwarding Problem B doesn't affect reliability (from the recipient
perspective) at all, unless the forwarder starts playing Tit for Tat to
force the recipient to eat his spam instead of causing deadletters.

Forwarding Problem S can be avoided easily by the recipient, by not
deploying receiverside SPF.

Forwarding Problem K could cause "reliability problems", but it's only an
issue at Karma-counting final mailstores.

---- 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=93127865-92ca6f
Powered by Listbox: http://www.listbox.com
Re: Statement of Problems and Requirements (Last Call) [ In reply to ]
Michael Deutschmann wrote:
> On Wed, 6 Feb 2008, David MacQuigg wrote:
>> Problem P - Recipients have difficulty keeping track of and updating
>> their forwarding arrangements.
>
> These aren't like the three forwarding problems I've laid out.
>
> Problem P is a root cause of my three problems, but is not a forwarding
> problem in and of itself.
>
> It's not even THE root cause -- it shares credit with recipient
> indifference to the other forwarding problems.

Perhaps it is rather a symptom than a problem. The symptom tells that the
email transport system lacks something that is quite fundamental in a
communication system. Historically, both surface mail and telephone agreed
that the caller pays the expenses while the callee has no obligations.
Email puts it rather differently. Indeed, it used to be a mere utility for
exchanging messages until a decade ago.

I cannot claim that solving problem P affects the more forwarding-specific
problems S, B, and K. However, the only kind of solution I'm able to
imagine for solving P -namely keeping track of message paths- provides for
coping with S, B, and K too. Let me put some examples below.

> If:
>
> * legitimate mail from <sarah@example.com> to <fred@example.org> is
> forwarded to <ralph@example.net>, run through SpamAssassin by example.net
> and then delivered to Ralph's mailbox.

IMHO fuzzy filtering should stay near to the end, possibly on Ralph's MUA.
However, different people may have different opinions on different
filters. By tracking forwarders along message paths, collecting each one's
capabilities along the way, Ralph could be able to configure what filters
will be activated where, for messages destined to him.

> * false-postive mail from <sarah@example.com> to <fred@example.org> will
> be bounced to <sarah@example.com> when Example.net 5xxs example.orgs
> the attempt to forward to Ralph.

Forwarding occurs for different _reasons_, ranging from mailing lists to
anonymization. Bounces are meaningful in certain cases and useful for
specific actors, and should be directed accordingly. It is the recipient's
responsibility to classify each forwarding recipe properly.

> * actual spam, forged in <sarah@example.com>'s name and sent to
> <fred@example.org>, will also be bounced to <sarah@example.com> when
> Example.net 5xxed it.

When forwarding will have been fixed, example.com and example.org will
have no excuse for not enabling SPF, resp. publishing and checking.

> ...then Forwarding Problem B is active. But Ralph doesn't mind. If his
> spam-filter triggers, he doesn't worry because he knows the original
> sender will know from the bounce that the mail wasn't delivered,

(The sender will also know the implicitly leaked target mailbox name.)

> and if it
> was indeed spam, he never had to acknowledge seeing it.
>
> Sarah will be angry about the backscatter, and will sic the Lumber Cartel
> (TINLC) on Example.org, but Ralph *doesn't care about that*.

Privacy directives also address direct mail. Whether opt-in or opt-out
would be enforced under specific circumstances, no evidence that either
has ever occurred is currently being collected, thereby clogging any legal
action.

This facet of the (P) privacy problem is not very well expressed by its
current short description.

> The only way Ralph will care is if Example.org *deliberately* breaks his
> forwarding to punish him.

That implies communication between Ralph and example.org is at stake.
While example.org can always send automated messages to ralph@example.net,
Ralph has to get personally in touch in order to reply. Tracking
forwarders yields reverse paths as an added value.

-------------------------------------------
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=93492651-935ffb
Powered by Listbox: http://www.listbox.com
Re: Statement of Problems and Requirements (Last Call) [ In reply to ]
Scott Kitterman wrote:
> On Saturday 09 February 2008 15:29, WebMaster@commerco.net wrote:
>> Scott,
>>
>> At 12:33 PM 2/9/2008, you wrote:
>>>On Saturday 09 February 2008 13:41, David MacQuigg wrote:
>>>> At 11:59 PM 2/6/2008 -0500, Scott K wrote:
>>>>> Are we calling forwarders, forwarders yet or are you still changing
>>>>> existing terminology?
>>>>
>>>> we are using the term "forwarding" in a more limited way
>>>
>>> Any approach that takes the view "We are using words you are used to, but
>>> to mean different things." is doomed to fail.
>>
>> I appreciate the spirit of your statement and tend to agree with it,
>> but I don't think that is what Dave is doing or talking about here.
>
> So far every time I read these suggestions I find words are meant to mean
> something other than what I think they mean.

"Forwarder" an "forwarding" are not really jargon terms outside of these
threads. "Relay" is the proper term. When we say "forwarder" we don't mean
an MSA, for example. In that respect, we limit its meaning.

As long as we make acceptable limitations to the natural language terms, I
think it should be acceptable.

> There is a clear distinction between relaying and forwarding (rcpt to doesn't
> change in relaying). Trying to conflate them just adds to the confusion.

Rcpt MAY change in relaying: That's the generic wording, e.g. from rfc2821:

any further (forwarding, gateway, or relay) systems MAY remove the
return path and rebuild the MAIL command as needed

In facts, if a relay didn't change the RCPT, messages would just jump from
sender's MSA to the MX destination host, possibly via backup MXes. That's
what forwarding is all about. BTW, the latter argument also leads to the
conclusion that there is a unique boundary along the message path, between
MON and MRN.

IMHO, the confusion stems from the IETF having apparently lost its ability
to specify standards. One may wonder why rfc2821 explains relaying with
examples grabbed from the email museum, like so:

For example, mail received at relay host xyz.com with envelope
commands

MAIL FROM:<userx@y.foo.org>
RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>

will normally be sent directly on to host d.bar.org with envelope
commands

MAIL FROM:<userx@y.foo.org>
RCPT TO:<userc@d.bar.org>

As provided in appendix C, xyz.com MAY also choose to relay the
message to hosta.int, using the envelope commands

MAIL FROM:<userx@y.foo.org>
RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org>

or to jkl.org, using the envelope commands

MAIL FROM:<userx@y.foo.org>
RCPT TO:<@jkl.org:userc@d.bar.org>

Of course, since hosts are not required to relay mail at all, xyz.com
may also reject the message entirely when the RCPT command is
received, using a 550 code (since this is a "policy reason").

Is the IETF becoming the Internet Museum?

> It's impossible for me to tell without clear language. I get very nervous
> about threads entitled last call when the language isn't at all clear.

That was also David's concern. However, all language terms are final when
they are dead. I tend to understand "last call" as obviously implying the
last one *thus far*.

>> After we have gone through the process, we can revisit the
>> terminology, if needed.

I agree, and that should be focused on specific terms.

> I take the opposite view. Any solution written in impenetrable jargon that
> no one outside the group of jargon developers can understand is no solution
> at all.

I also agree. Our private jargon is good for internal discussions and
documents. Any writing meant to be comprehensible to a wider public has to
include the definition of any term whose meaning we will consider relevant
or useful for clear writing. For some writings, we can use circumlocutions
that would annoy ourselves if used every day.

-------------------------------------------
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=93492651-935ffb
Powered by Listbox: http://www.listbox.com
Re: Statement of Problems and Requirements (Last Call) [ In reply to ]
At 03:44 PM 2/9/2008 -0800, you wrote:

>On Wed, 6 Feb 2008, David MacQuigg wrote:
>> Problem P - Recipients have difficulty keeping track of and updating
>> their forwarding arrangements.
>
>These aren't like the three forwarding problems I've laid out.

I've marked problems P and R as "related problems", since they are not forwarding problems in and of themselves.

-- Dave


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Modify Your Subscription: http://www.listbox.com/member/?member_id=1311532&id_secret=94780945-262228
Powered by Listbox: http://www.listbox.com