spf-discuss
[Top] [All Lists]

RE: [spf-discuss] Misuse of Return Address

2006-12-06 20:09:51
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.


Even if we add outgoing mail services we will still have a problem
trying to force changes on the world.  Our recipients do not want to
change their email programs, their ESPs, or anything about the way
they do business.  It is even a bit much for them to deal with our
subject-line tagging - [], [*], [**], [**spam**}.  As one of our
first beta testers put it - "Just get rid of the spam, and spare me
the details."

Everyone would like a solution that requires no change and solves the
spam problem.  It's pretty clear that doesn't exist.  The practical
question is, what are the biggest returns for the smallest changes that
cause the least breakage.  Anything that you can achieve at the envelope
stage has the highest return, as you close the socket, avoid receiving
data or dump any data already in your buffer without examining it.

SPF does not require changes from the rest of the world.  SPF is nothing
more than a framework for a domain owner to tell a recipient how to
detect forgeries of their domain based on hosts they designate to emit
mail with their domain name in the return-path.  As a domain owner, you
have to consider if there are any instructions you can give to
recipients that will help them reject forgeries of your domain name
based on originating host.  If there not, then don't publish anything.
To the extent that you can change your mail setup to make it easier for
recipients to detect forgeries of your domain name, it may be to your
advantage to do implement them.


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.


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.

--
Seth Goodman

-------
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