spf-discuss
[Top] [All Lists]

Re: [spf-discuss] Re: Forwarder whitelisting reloaded

2008-01-19 04:34:56
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=2183229&id_secret=87770468-9273b7
Powered by Listbox: http://www.listbox.com

<Prev in Thread] Current Thread [Next in Thread>