spf-discuss
[Top] [All Lists]

Re: Maybe simple question

2003-12-15 00:42:53
----- Original Message ----- 
From: "Vivien M." <vivienm(_at_)dyndns(_dot_)org>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Monday, December 15, 2003 5:34 AM
Subject: RE: [spf-discuss] Maybe simple question

Hello Vivien,

The problem with SPF is this: anyone who has SPF records must provide an
SMTP AUTH (or other mechanism) relay for its users once they leave that
organization's IP pool. That's what I think Mr. Harvey was trying to
argue, and a serious problem for some people.

But this is not an SPF issue, per se. All relays are inherently "closed"
(unless they are grossly misconfigured), with or without SPF. So, basically,
everyone "must provide an SMTP AUTH (or other mechanism) relay for its users
once they leave that organization's IP pool," with or without SPF. The
administrator of such a relay can decide to add "Trusted Mechanisms" (in
sendmail terms), that will allow for a relay from outside the organization's
IP pool; like SMTP AUTH, or DRAC (Dynamic Relay Authorization Control). But,
like I said, that is not an SPF matter, per se; not being an open relay, and
providing trusted mechanism to deal with relays from foreign IP space, is
just responsible system administration. :)

If, however, you want to have people from
outside your netblock send mail, then it requires you to set up (and pay
for, and maintain, and secure, etc) a way for them to send it - whereas
before, they would send through their local ISP's SMTP server, which they
are after all paying for (and will continue to pay for, but not use, with
SPF).

The way I see it, for the home user, there are four distinct situations:

1): He sends mail through the SMTP server of his ISP, using an envelope from
address with the domain name of the ISP. In this case, there is no problem,
as SPF queries (at the machine your ISP's SMTP server relays to) will be
targeted at the DNS server of the ISP (who, itself, has published SPF
records that include its own SMTP servers). And you have authenticated
yourself to your ISP's server, using SMTP AUTH, or DRAC.

2): He sends mail through the SMTP server of his ISP, using an envelope from
address with a domain name of another ISP. Barring explicit agreements
between those ISP's, under SPF, you can, indeed, no longer do that. That is,
you cannot send out mail using an SMTP server of AOL, using an
@mindspring.com address (unless, like I said, mindspring published an SPF
record which specifically allowed the AOL SMTP server to relay mail for
them; yeah, right).

3): He sends mail through the SMTP server of his ISP, with an envelope from
address using a domain name under his own DNS control. Possible, but not
ideal. Then you get the quandary Mr. Harvey got himself into: in your own
SPF records you need to designate a third-party as 'trusted' to handle your
mail. SPF queries will be targeted at your own DNS, where you designated
your ISP's mail servers as trusted.

I would like to point out, though, that the Nr. 3 scenario is unlikely,
IMHO. I mean, if you run your own DNS, chances are you run your own mail
server too. Or, rather, if you let your ISP handle all your Internet
Services, why bother running your own DNS?

4): He sends mail through his own SMTP server, with an envelope from address
using a domain name under his own DNS control. That, I reckon, is the ideal
SPF situation. SPF queries will be targeted against your own DNS, in which
you published SPF records that designate your own mail servers as trusted.

What category is your dad in? :)

- Mark

        System Administrator Asarian-host.org

---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx

-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡


<Prev in Thread] Current Thread [Next in Thread>