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
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
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
* 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
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription:
Powered by Listbox: http://www.listbox.com