As I've been following the SPF, SRS and now IETF MARID
discussion closely for some time now I'd like to throw my $0.02 worth
into this discussion. As well I happen to publish SPF data for my
personal domain. I currently have my MX servers not doing SPF checking
due to resource limitations on the machines (currently on really old
hardware).
On Tue, May 18, 2004 at 11:38:40AM -0300, Henrique de Moraes Holschuh wrote:
> Yes, it indeed does. You have to either direct all email to an
> authenticated SMTP host that is on your SPF profile (should not be a problem
> for Debian, we have more than enough resources and know-how to configure
> this, and even to buy another smtp-outgoing machine if we really want to)...
>
> Or we have to add a few key bits to the LDAP gateway and DNS zones to
> publish SPF data from the developers, which is less "secure" (unless SPF
> does user@domain these days, instead of just @domain).
>
SPF does look at the right hand side thus if the RFC-2821 MAIL
FROM is user@domain.tld it looks for domain.tld by default, whereas if
it is user@host.domain.tld it looks for host.domain.tld and will not
look at domain.tld unless the entry for host.domain.tld refers to it.
As well there are macro methods which could be implimented which
would allow for valid email addresses to succeed in pasing SPF checks.
This could be used to just check for a given email address existing or
use of a given email address being sent from a specific IP address. So
for example we could propose the publishing of the following SPF data
for @d.o:
"v=spf1 a mx ptr exists:%{ir}.%{l}._spf.%{d2} ~all"
or alternatively
"v=spf1 a mx ptr exists:%{l}._spf.%{d2} ~all"
As well you could combine and use both of the "exists"
mechanisms together to cover both situations. Using myself for an
example for both of these it would mean adding records for any of the
following to match this SPF data:
#1 170.245.174.64.jbouse._spf.debian.org
#2 171.245.174.64.jbouse._spf.debian.org
#3 jbouse._spf.debian.org
The first two correspond with the first SPF data example and would
authorize mail sent as jbouse@debian.org to from my two MX servers but
would not allow from any other system unless it matched the rest of the
SPF data for d.o. The third corresponds with the second SPF data example
and would allow mail addressed as from me from any host regardless of
the sending machines IP address.
Clearly the difference between the two becomes apparent but
shows the flexibility that could be utilized to create SPF data that
would atleast attempt to curb the rampant forgery of d.o addresses as
the sender. The examples I gave did have a softfail (~all) option so it
would allow for implimentation now without adversely affecting email
deivery but tag mail it found suspect. Later it could be turn'd to a
hard failure (-all) when it was felt refined.
> Anyway, should there be real interest in @d.o under SPF, we could deploy it
> with little pain, as long as we have at least one auth'ed SMTP forwarder
> developers can use if they are in a really bad network position (i.e. they
> don't have one under their control).
>
> What pisses me off in SPF is the need for bounces to go the entire chain
> back, instead of directly. But for Debian, this is a non-issue, since that
> _already happens anyway_, and since our list servers ARE or HAVE their own
> forwarding SMTPs.
>
As already mention'd the spec states only the first and last
hops are necessary with regards to bounces.
Regards,
Jeremy
Attachment:
signature.asc
Description: Digital signature