At 09:07 PM 12/6/2006 -0600, you wrote:
David MacQuigg wrote on Wednesday, December 06, 2006 3:37 PM -0600:
> Box67.com is a recipient's forwarding service. It does not provide
> SMTP AUTH, outgoing mail, mailstorage, POP accounts, webmail, or
> any of the other features offered by a full-service ESP (email
> service provider) or a typical company mail server.
If box67.com injects any mail into the internet mail stream, whether as
a forwarder or as an originator, box67.com sends outbound mail. If it
does not inject any mail into the internet mail stream, there is no need
for an SPF record.
Whoa!! We're getting way too broad with the definition of "inject". I
guess it now includes allowing a forwarder to use box67.com in a Return
Address. "Allowing" includes not publishing an SPF record at all (same as
?all). So is box67.com responsible for the mail it "injects" if there is
no SPF record? How about a domain that has only a website, and is not even
involved in email. Is it responsible for the mail it "injects"?
I prefer the terms transmit and forward. The parties responsible (in our
system) are the operators of those transmitters, and the owners of domains
in the HELO name that specifically authorize those actions. We don't take
?all as an authorization for HELO, but any transmitters that are
specifically listed in an SPF record are authorized. We ask our clients
with SPF records to limit their creativity, and just use a:, mx:, and ip4:
terms for their own transmitters, and include: for any forwarders.
> The one big thing we must ask our recipients to do is change their
> Reply-To/Return address. For now, that is the only way they can use
> our authentication/reputation system. That will change soon, however,
> when we have a package they can have their admins download and install
> on their own mailserver. Then they can have their own strict SPF
> record, and box67.com is not involved.
You don't want to ask anyone to change anything, but you're offering a
package for a foreign domain to install on their mailserver? This
sounds extreme. It would be a lot easier to have users of foreign
domains submit mail to your MSA over port 587, which generally requires
no changes in the foreign MTA. Foreign users do have to set up their
MUA's to submit mail properly, but that is a one-time configuration that
doesn't involve any new software.
Think of our Border Patrol package as an open-source replacement for a
$2000 per year "spam appliance".
> We don't want to encourage misuse of the Return Address, but we have
> to accept it because we cannot expect our clients to change their
> email programs.
In that case, you have to accept that more casual forgeries of your
domain name will be accepted at recipients. There's no magic here and
no free lunch. Recipient MTA's have no way of knowing which MTA's can
use your domain name in the return-path if you don't tell them. If you
don't control use of your domain name, then you can't help them reject
forgeries. Since malicious forgery has become so prevalent, domains
must consider if continuing to allow trivial forgeries is worth a small
amount of added convenience for remote users.
It is my understanding that ?all has the same effect on unauthorized
transmitters as not publishing an SPF record at all. If it ends up somehow
counting against us, then we'll drop the SPF record entirely. I'll try
-all, but I can't promise I'll stick with it.
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735