Michael Deutschmann wrote:
But a "forwarding problem solution" that tried to do that would be too
complicated to implement all at once. To reach that heaven, we need to
gradually build up a tower of protocols, each terrace offering a small
improvement for a small amount of work.
* Level 0: Status quo, people are afraid to use receiverside SPF.
I'd also mention they are afraid to use backup MXes. After Frank said "it
might work", I'd like to try and solve both problems at once, for we may
gather more consensus that way.
* Level 1: TENBOX/E. Forwarder whitelisting is possible for power users.
The recipient asks his mail admin to whitelist mail bearing the SWK for
the forwarding relationship.
L1 implies the forwarder can authenticate itself, or the MTA has been
patched in order to implement TENBOX/E, or I haven't grasped TENBOX/E
quite enough. :-)
Shouldn't we "just" provide an rfc 1425 SMTP extension for forwarding?
* Level 2: As Level 1, but a protocol is added to allow the Forwarder to
enquire as to whether his SWK is truly whitelisted by a given recipient
mailbox, allowing some idiot-proofing.
What's wrong with just checking the response to "MAIL FROM:<> AUTH=<swk>"
or whatever TENBOX/E will prescribe?
* Level 3: TENBOX/O. A means is provided for the forwarder to identify a
special mailbox to send automated requests for whitelisting. On receiving
a request, a TENBOX/O supporting ISP will then internally generate a
confirmation message and add the SWK to a whitelist if the recipient
* Level 4: Means are added to allow the forwarder to collect "This is
Spam" results from the mails it has sent in the past.
Fine. L3 and L4 don't really have to come in that order. Actually, L4
seems more urgent to me...
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