On Wed, May 25, 2005 at 05:59:23AM -0400, John Glube wrote:
I travel a lot and use my laptop while on the road,
connecting through my wireless connection. Should this not
be possible, I want to be able to use any machine that is
available at the time, along with any Internet connection
to send email through my server.
Delivery of my personal, business and transactional email
is mission critical. I can't afford to have this kind of
email go missing because of a problem with mail forwarding
and SPF.
Would you advise this individual to publish a closed or
open SPF record, given the present state of the email
infrastructure?
"... through my server ..."
You are connecting to your infrastructure, sending messages
through your infrastructure. We will be getting these messages
from your infrastructure, not from "any machine".
This seems to call for "v=spf1 +yourmachines -all".
If you mean "forwarding" as in transfering a message from one
MTA under your control to the next one under your control:
SPF does not apply.
If you mean "forwarding" as in resending the message performed
by receivers and using your name, that's their problem. If you
want to make it your problem, do not use "-all".
By publishing "-all", the domain owner does indeed state that
others, such as "forwarders" (resubmitters IMHO) are NOT
authorized to use other people's domain names.
This is the whole point of SPF. There's no difference between
a spammer saying "MAIL FROM:<jbglube(_at_)sympatico(_dot_)ca>" and a
forwarder saying "MAIL FROM:<jbglube(_at_)sympatico(_dot_)ca>". In both
cases, they are or are not authorized to use "sympatico.ca"
If you want to allow the whole world to use sympatico.ca in
SMTP transactions, don't publish SPF, publish "?all" or even "all"
If you want to receive bounces only for mail you actually transmitted,
(not: created !) you publish "-all"
If you accept responsibility for a message (by ending an SMTP transaction
with "220 message accepted" and decide to resend this message to another
trust domain, use your own name as SENDER.
Don't compound the design errors by mixing apples and
oranges. The HELO and SMTP MAIL FROM serve different
purposes. As I understand it, the HELO address identifies
the server making contact. The SMTP MAIL FROM address is
the address to which delivery status notices are sent. Each
identity serves a different purpose.
Don't look at it from a receiver's point of view. It is
SENDER policy.
The sender is saying something about both the SMTP MAIL FROM
and the HELO arguments.
Given this policy:
mail.domain.tld TXT "v=spf1 a ip4:1.2.3.4 -all"
It is alright for the box with name "mail.domain.tld" to say
HELO mail.domain.tld
It is alright for the box on ip address 1.2.3.4 to say
HELO mail.domain.tld
Presumably this host "mail.domain.tld" has an extra nic with
address 1.2.3.4 and this nic does not share the FQDN with the host.
A host MUST use its FQDN if available, even on nic 1.2.3.4 and
ptr(4.3.2.1.in-addr.arpa) does not resolve to "mail.domain.tld"
No problem: SPF can handle it.
All other hosts are not authorized to say HELO mail.domain.tld
After the HELO is authorized, you have sufficient trust in it's
authenticity and can accept "MAIL FROM:<>" from it. No sooner.
This doesn't mean you will accept such a bounce. Maybe the host
is on a blacklist.
This same box is also authorized to "MAIL
FROM:<user(_at_)mail(_dot_)domain(_dot_)tld>"
Again: this doesn't necessarily mean you accept the message. It does
however mean that no spammer or virus claims to be you.
Additional policy:
domain.tld TXT "v=spf1 a:mail.domain.tld -all"
The host with name mail.domain.tld is authorized to use domain.tld
in it's MAIL FROM commands. Presumably this host (which has an
extra nic with address 1.2.3.4) does not send domain.tld mail out
via [1.2.3.4]. This can happen, it might HELO as mail.domain.tld
and use MAIL FROM:<user(_at_)otherdomain(_dot_)tld>
For this reason, each identity deserves its own design
approach, which requires a separate protocol so allowing
focused effort being placed on the problems and
difficulties surrounding the use of that identity for the
purpose of email authentication, given the complexity of
the email infrastructure.
Do you still feel that way, after my examples?
Alex