headers
Wayne Schlitt | 1 Mar 2004 08:23

Weekly SPF discussion mailinglist stats for 03/01/04

The following were the top 15 posters to the SPF discussion mailinglist for
the week ending 03/01/04:

Total Posts:  227       Individuals Posting:  46
     38 Meng Weng Wong <mengwong@...>
     23 Hector Santos <winserver.support@...>
     20 wayne <wayne@...>
     17 David Woodhouse <dwmw2@...>
     16 Ernesto Baschny <ernst@...>
     12 Mark <admin@...>
      9 <list+spf-discuss@...>
      8 Theo Schlossnagle <jesus@...>
      7 Dustin D. Trammell <dtrammell@...>
      7 Alex van den Bogaerdt <alex@...>
      6 Greg Connor <gconnor@...>
      4 Seth Goodman <sethg@...>
      3 jm@... (Justin Mason)
      3 Za'mbori, Zolta'n <zamboriz@...>
      3 Roy Badami <roy@...>
Permalink | Reply | 0 comments |
headers
David Woodhouse | 1 Mar 2004 10:33
Favicon

Re: Deployment dynamic: LMAP vs MTA registration schemes

On Sun, 2004-02-29 at 18:26 +0000, Dan Boresjo wrote:
> Quite the opposite: provided that using or not using HEAD does not affect the 
> ultimate chances of acceptance, there is no reason for spammers to avoid it.
> 
> Indeed since their messages are more likely to be rejected, spammers would 
> benefit from the bandwidth savings just as much as their victims. 

This might be true, I suppose. 

> Unfortunately there is no benefit for legit senders - they do not expect a 
> significant proportion of their messages to be rejected!

But OTOH they do want it to be the norm... you only have to get the MTA
authors to make it the default to advertise and use this feature. 

--

-- 
dwmw2
Permalink | Reply | 0 comments |
headers
Jim Ramsay | 1 Mar 2004 15:47
Gravatar

Re: Signed Envelope Sender: SRS on steroids

Meng Weng Wong wrote:

> It's a little bit like VERP and and TitanKeys and TMDA, except that the
> tags aren't just plaintext but are cryptographically generated with a
> secret.

For the record, TMDA is also cryptographically generated with a secret.

Also, TMDA offers three different "types" of envelopes you can use (all 
cryptographically generated of course!):

- Dated (expires after specified timeout)
- Keyword (never expires, may have to be revoked :read - blacklisted: if 
harvested)
- Sender (Only accepted if sender envelope matches what I generated it with)

--

-- 
Jim Ramsay
"Me fail English?  That's unpossible!"
Permalink | Reply | 0 comments |
headers
Dustin D. Trammell | 1 Mar 2004 19:54

Re: Possible SPF machine-domain loophole???

On Sun, 2004-02-29 at 17:55, list+spf-discuss@... wrote:
> --On Sonntag, Februar 29, 2004 16:08:42 -0500 Theo Schlossnagle 
> <jesus@...> wrote:
> > Maybe someone can explain to me why this is an issue at all.  If we are
> > in here mucking with the MTA anyway (for SPF) why don't we just mandate
> > that the MTA does away with putting the domain in the Received header
> > like that.
> 
> Because RFC2821 states the exact opposite:
> 
>    -  The FROM field, which MUST be supplied in an SMTP environment,
>       SHOULD contain both (1) the name of the source host as presented
>       in the EHLO command and (2) an address literal containing the IP
>       address of the source, determined from the TCP connection.

Note that you MUST supply the FROM field, however it SHOULD contain both
the ehlo string and the address.  RFC 2119 section 3 states:

"3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there 
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course."

Not being able to intelligently determine that the string passed via
ehlo and the address that is connecting are in fact related sounds like 
a fairly valid reason in this circumstance to not include the ehlo
string to me.  So what we really need to determine is whether or not
leaving that information out will have consequences other than
uneducated users no longer misinterpreting the header.  We should not
reject the idea entirely because precedent has always been to include
(Continue reading)

Permalink | Reply | 0 comments |
headers
wayne | 2 Mar 2004 00:36

ANNOUNCE libspf-alt version 0.2


A new version of the alternate C implementation of SPF (libspf-alt) is
now available at:

http://www.midwestcs.com/spf/libspf-alt

Version 0.2 is mostly a cleanup release.  The major change is that
libspf-alt now uses autoconf/configure to make it more portable.  It
now compiles and passes its self-checks on Debian Linux (testing),
FreeBSD 4.3 and SunOS 5.8.  The source code has been rearranged, it is
now in a directory tree rather than everything in one big directory.
The six different test suites that I've been using for testing can now
be automatically run by using the "make check" command.

The GNU autoconf/automake/libtools system (configure) gives a nice
standardized system for things like "make install" and "make
uninstall", but boy does it add bulk!  The configure script alone is
over 750k!  Still, I think using these tools is well worth it.

Comments, suggestions, bug reports, and complaints, are welcome!

-wayne

-------
To unsubscribe, change your address, or temporarily deactivate your subscription, 
please go to http://v2.listbox.com/member/?listname=spf-devel-B7dvP5mc3PhiK979QBapAg <at> public.gmane.org
Permalink | Reply | 0 comments |
headers
Thomas H Jones II | 3 Mar 2004 01:37

Re: SPF Server

David Brodbeck wrote:

>On Fri, 27 Feb 2004, Casey West wrote:
>
>  
>
>>I commend you for your interest, and if you aren't worried about
>>liability (Is it really an issue? Do RBLs get legal threats for
>>blocks?)
>>    
>>
>
>You better believe they do.  Some of the big ones have been the target of
>multiple lawsuits.
>
Perhaps best to leave the running of such servers to hard to pin down 
groups such as SPEWS, eh?

-tom
Permalink | Reply | 0 comments |
headers
Jeroen Massar | 3 Mar 2004 01:52
Favicon
Gravatar

ip6 mechanism + signing messages


Hi,

http://spf.pobox.com/mechanisms.html#ip6 mentions
that "Could someone with IPv6 experience please provide some input?"

Basically for my domain, my SPF IPv4 DNS entry would be:

unfix.org. IN TXT "v=spf1 ip4:195.64.92.136 -all"

But as I require it to do IPv6 also it would become:

unfix.org. IN TXT "v=spf1 ip4:195.64.92.136 ip6:3ffe:8114:2000:240:290:27ff:fe24:c19f -all"

The IPv4 address has to be listed because my IPv4
provider doesn't make it able to change reverses.
For IPv6 that is no problem and I could also list
purgatory.unfix.org there, which is the same box.

Wellps the only thing I can say is that the above
is quite ambigous for parsing and if SPF would
adapt RFC 2732 it would read:

unfix.org. IN TXT "v=spf1 ip4:195.64.92.136 ip6:[3ffe:8114:2000:240:290:27ff:fe24:c19f] -all"

Which is a bit more clear imho, or if you have
a netblock, using the example 2001:db8::/32
block, which you should use in documentation:
example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 ip6:[2001:db8::/32] -all"
(Continue reading)

Permalink | Reply | 5 comments |
headers
Aredridel | 3 Mar 2004 06:14
Gravatar

Re: ip6 mechanism + signing messages

> example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 ip6:[2001:db8::/32] -all"

More often ip6:[2001:db8::]/32 -- mask outside. Not always uniform
everywhere, though.

Ari
Permalink | Reply | 0 comments |
headers
Lars Dybdahl | 3 Mar 2004 09:23

SV: ip6 mechanism + signing messages

> On another note, to extend SPF wouldn't it be
> a good feature to add something like:
> example.com IN TXT "v=spf1 sig:sigserver.example.net"

> The 'sigserver.example.net' box could then run
> a whois like directory which contains PGP (or other)
> signature methods just like the current pgp keyservers.

SPF was not designed to be used on the e-mail after receiving the e-mail
body - but the idea of letting the DNS system point at a PGP keyserver
is very good.

Unfortunately, I think that some people might get a bit confused about
the SPF concept if PGP/GnuPG is getting involved with SPF now. SPF
deployment isn't that big, yet, and introducing PGP/GnuPG will introduce
a lot of explaining and many existing SPF explanations and arguments
will have to be modified (like the one that e-mails get rejected before
receiving the message body).

Maybe another kind of TXT record would be the right way to do it?

Lars Dybdahl.
Permalink | Reply | 501 comments |
headers
David Woodhouse | 3 Mar 2004 09:45
Favicon

Re: ip6 mechanism + signing messages

On Wed, 2004-03-03 at 01:52 +0100, Jeroen Massar wrote:
> On another note, to extend SPF wouldn't it be
> a good feature to add something like:
> example.com IN TXT "v=spf1 sig:sigserver.example.net"
> 
> The 'sigserver.example.net' box could then run
> a whois like directory which contains PGP (or other)
> signature methods just like the current pgp keyservers.

What's wrong with just putting the key into the SPF record too?

In general don't want to use GPG because it involves MIME (or other
noise) and won't always survive mailing lists, and because to many
people a GPG signature implies a level of trust far above what's
appropriate with SMTP AUTH.

I've been toying with alternative methods of signing content, which life
unobtrusively in the headers and should survive a little bit of
mangling. See
http://lists.infradead.org/pipermail/sender-auth/2004-February/000015.html
for some details.

--

-- 
dwmw2
Permalink | Reply | 1 comment |

Gmane