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(_at_)sender(_dot_)com is sent to
dave(_at_)forwarder(_dot_)org, where it is forwarded to
dave(_at_)mda(_dot_)net, keeping the original Return Address,
tom(_at_)sender(_dot_)com(_dot_) 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(_at_)mda(_dot_)net(_dot_) 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(_at_)mda(_dot_)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=2183229&id_secret=92536520-73566a
Powered by Listbox: http://www.listbox.com