WebMaster(_at_)Commerco(_dot_)Net wrote:
At 03:59 AM 1/12/2008, you wrote:
May I suggest that we use a community web page on openspf.org
for writing a glossary
Excellent thought, although I'm wondering if a glossary of definitions
is not there, why not simply have it in the spec itself?
I think the spec should be understood by the community at large, so they
should use terms from the rfc 1983 glossary. Yet, it is possible that we
come out with concepts that deserve inclusion in a wider community's
parlance.
FWIW, I wouldn't deem "transmitter" as defined in
http://open-mail.org/3strikes/QnA.html
is a useful term. Indeed, its definition implicitly refers to a boundary
even though that doesn't transpire from the term itself --as it does, for
example, in "MON", where "N" for Network implies a network boundary. And
it conflicts with the generic use of "transmitter" as the receiver's peer.
David MacQuigg wrote:
Again, no recognition of a single, most-important Border.
Even worse from an SPF point-of-view, this diagram
implies there are "Transit ADMDs" with no relationship to
either side.
Borders are particularly insidious for SPF. "ADMD" has different meanings
when its administrative management affects DNS, IPs assignment, or SMTP
configuration. In addition, large organizations are partitioned into
internal subunits, which may wish to carry out SPF checking one against
the other. I don't think we can pull out any useful topology from that.
A forwarder who knows it is whitelisted by a specific receiver may assume
no borders are crossed on forwarding to that receiver. Does that imply it
won't replace the original envelope sender?
-------------------------------------------
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=85366849-083184
Powered by Listbox: http://www.listbox.com