[OT] SPF - Do you use it

[Titanus Eramius]

Slightly off topic. I hope it's OK when the mail is marked as such.

I was just wondering if the users of this list use SPF in any way, and
if so, to what extend?

My former provider of mail added a header with the SPF-info retrived
from DNS, and I'm considering to do the same with "policyd-spf-perl".
There is already a running DNS on the system, so the extra lookup
should not have a lag.

I already have Perl installed through the use of postfixAdmins auto
reply script, so it seems natural to choose a solution written in Perl
(if a choice exists).

The only policy deamon I am currently using is greylisting by SQLGrey.

The mailserver only provides me with my personal mail, so the
load is very light.

[Reindl Harald-2]

Am 05.10.2012 15:43, schrieb Titanus Eramius:
> Slightly off topic. I hope it's OK when the mail is marked as such.
>
> I was just wondering if the users of this list use SPF in any way, and
> if so, to what extend?

yes because it is no additional work since our admin-backend adding
them with a central configuration to each generated bind-zone and
it has the benefit that other servers can reject spam with forged
senders using one of our domains

thelounge.net.          43200   IN      SPF     "v=spf1 ip4:91.118.73.0/24 ip4:89.207.144.27 -all"

and for zones without a MX the following to state that this
domain does not use e-mail at all

afi.at.                 43200   IN      SPF     "v=spf1 -all"

[Reindl Harald-2]

forgot to mention you should use BOTH types
TXT and SPF

thelounge.net.          43200   IN      SPF     "v=spf1 ip4:91.118.73.0/24 ip4:89.207.144.27 -all"
thelounge.net.          43200   IN      TXT     "v=spf1 ip4:91.118.73.0/24 ip4:89.207.144.27 -all"
_________________________-

TXT RR Format

The standard TXT and SPF record format is defined as:

name  ttl  class   TXT     text
name  ttl  class   SPF     text

The SPF RR is functionally identical to a TXT record with SPF data. BIND 9.4+ supports the SPF RR type, however
previous versions, and most other DNS software (as of July 2007), do not yet support the SPF RR type. Thus, the
RFC's recommendation is to always provide a TXT based SPF RR and, if your DNS software supports the SPF RR type,
duplicate the information from the TXT version of the SPF RR in a native SPF RR. The reason for this procedure is
simply because while the master/slave DNS may support the SPF RR, querying name servers - such as name servers used
by receiving MTAs - may not. Some, but not all, of the examples below have been updated to reflect the use of both
record types to illustrate usage. In all cases the TXT and SPF RRs are shown with a comment line between containing
the word AND as a reminder of the current policy recommendation. It is safe to assume for the foreseeable future
that only using a TXT version of the SPF will always work.

[lst_hoe02]

Zitat von Titanus Eramius <[hidden email]>:

> Slightly off topic. I hope it's OK when the mail is marked as such.
>
> I was just wondering if the users of this list use SPF in any way, and
> if so, to what extend?

We have considered SPF some five years ago but after second thought  
ditched it completely:

- It dos not really help against spam because the spam-farms also can  
set proper SPF

- It is not really useful for prove-of-sender because no MUA care about

- It does not add any aditional security/reliability to e-mail

- There are problems with forwarding

Instead we have installed a S/MIME Gateway which solve the  
prove-of-sender with additional benefits of making encrypted mail  
possible.

But as always YMMV

Regards

Andreas

[Alumno Etsii]

2012/10/5 <[hidden email]>

Zitat von Titanus Eramius <[hidden email]>:

Slightly off topic. I hope it's OK when the mail is marked as such.

I was just wondering if the users of this list use SPF in any way, and
if so, to what extend?

We have considered SPF some five years ago but after second thought ditched it completely:

- It dos not really help against spam because the spam-farms also can set proper SPF

- It is not really useful for prove-of-sender because no MUA care about

- It does not add any aditional security/reliability to e-mail

- There are problems with forwarding

Instead we have installed a S/MIME Gateway which solve the prove-of-sender with additional benefits of making encrypted mail possible.

But as always YMMV

Regards

Andreas

As far as I'm concerned, SPF is not an anti-spam tool, but an anti-forgery tool. And IMHO, if I'd need to say it's useful it's because it's not as extended as it may be; if everyone had configured the verification of SPF, mail forging would be reduced a lot. I use it both for personal and profesional purposes, at work we have rules for analyzing SPF results and it really helps. Definitely recommendable.

Regards.

[Reindl Harald-2]

Am 05.10.2012 16:04, schrieb [hidden email]:

>
> Zitat von Titanus Eramius <[hidden email]>:
>
>> Slightly off topic. I hope it's OK when the mail is marked as such.
>>
>> I was just wondering if the users of this list use SPF in any way, and
>> if so, to what extend?
>
> We have considered SPF some five years ago but after second thought ditched it completely:
>
> - It dos not really help against spam because the spam-farms also can set proper SPF

this point is simply wrong

a spam-farm CAN NOT set a SPF that whatever ip is allowed
to send mails with my envelope - simply because they are not
the dns-admin of my zones


SPF is NOT a spam-protection

it is designed to prevent forged sender-addresses which in
the worst case results in multiple auto-replies between
completly univolved persons which may over-react and
start blacklisting servers which are not the root-cause

the real problem is that not EVERY domain has SPF records
and that is why it doe snot help as much as it could, you
are part of this problem because ANYBODY can send me spam
with yur sender-address and only blacklists and bayesian
filters prevents my server to send you auto-replies for
such messages if i am at vacation

[Wietse Venema]

Alumno Etsii:
> As far as I'm concerned, SPF is not an anti-spam tool, but an anti-forgery
> tool.

I'm ending this discussion before the flames flare up.

Let's suffice with the following observation:

    SPF helps a sender and receiver who know each other. Otherwise
    it helps no-one.

The same holds for any system that relies on sender-provided
policy information including DKIM.

        Wietse

[Robert Schetterer]

Am 05.10.2012 15:43, schrieb Titanus Eramius:

> Slightly off topic. I hope it's OK when the mail is marked as such.
>
> I was just wondering if the users of this list use SPF in any way, and
> if so, to what extend?
>
> My former provider of mail added a header with the SPF-info retrived
> from DNS, and I'm considering to do the same with "policyd-spf-perl".
> There is already a running DNS on the system, so the extra lookup
> should not have a lag.
>
> I already have Perl installed through the use of postfixAdmins auto
> reply script, so it seems natural to choose a solution written in Perl
> (if a choice exists).
>
> The only policy deamon I am currently using is greylisting by SQLGrey.
>
> The mailserver only provides me with my personal mail, so the
> load is very light.
>

i use policyd-spf-perl
only selective for some domains
doesnt help very much, spammers have most valid spf

and setup all "my domains" with spf non strict
helps little for backscatter and may help deliver in at big mail providers

as spf breaks forwarding it should be avoided, dont use it if you dont
have to, use dkim

--
Best Regards
MfG Robert Schetterer

[lst_hoe02]

Zitat von Reindl Harald <[hidden email]>:

> Am 05.10.2012 16:04, schrieb [hidden email]:
>>
>> Zitat von Titanus Eramius <[hidden email]>:
>>
>>> Slightly off topic. I hope it's OK when the mail is marked as such.
>>>
>>> I was just wondering if the users of this list use SPF in any way, and
>>> if so, to what extend?
>>
>> We have considered SPF some five years ago but after second thought  
>> ditched it completely:
>>
>> - It dos not really help against spam because the spam-farms also  
>> can set proper SPF
>
> this point is simply wrong
>
> a spam-farm CAN NOT set a SPF that whatever ip is allowed
> to send mails with my envelope - simply because they are not
> the dns-admin of my zones
>
>
> SPF is NOT a spam-protection
>
> it is designed to prevent forged sender-addresses which in
> the worst case results in multiple auto-replies between
> completly univolved persons which may over-react and
> start blacklisting servers which are not the root-cause
>
> the real problem is that not EVERY domain has SPF records
> and that is why it doe snot help as much as it could, you
> are part of this problem because ANYBODY can send me spam
> with yur sender-address and only blacklists and bayesian
> filters prevents my server to send you auto-replies for
> such messages if i am at vacation

This is your opinion. Mine is i don't care what sender-addresses spam  
has but i care about preventing spam from reaching end users. The most  
spam we see are from well connected spam-farms with their own  
throw-away domains and proper SPF/DKIM set. So no, SPF/DKIM is not  
useful for us in any way but certainly you are free to use it the way  
you like and as long as you like.

Regards

Andreas

[lst_hoe02]

Zitat von Wietse Venema <[hidden email]>:

> Alumno Etsii:
>> As far as I'm concerned, SPF is not an anti-spam tool, but an anti-forgery
>> tool.
>
> I'm ending this discussion before the flames flare up.
>
> Let's suffice with the following observation:
>
>     SPF helps a sender and receiver who know each other. Otherwise
>     it helps no-one.
>
> The same holds for any system that relies on sender-provided
> policy information including DKIM.
>
> Wietse

+1

and my last post on this subject.

Regards

Andreas

[Titanus Eramius]

On Fri, 05 Oct 2012 15:50:37 +0200
Reindl Harald <[hidden email]> wrote:

> forgot to mention you should use BOTH types
> TXT and SPF
 
I did not even know that a SPF record type existed in DNS. At the
homepage of SPF and other places I have read, it is indicated that SPF
= TXT RR in DNS, but I may have read too little on the subject to
notice.

> The SPF RR is functionally identical to a TXT record with SPF data.
> BIND 9.4+ supports the SPF RR type, however previous versions, and
> most other DNS software (as of July 2007), do not yet support the SPF
> RR type. Thus, the RFC's recommendation is to always provide a TXT
> based SPF RR and, if your DNS software supports the SPF RR type,
> duplicate the information from the TXT version of the SPF RR in a
> native SPF RR. The reason for this procedure is simply because while
> the master/slave DNS may support the SPF RR, querying name servers -
> such as name servers used by receiving MTAs - may not. Some, but not
> all, of the examples below have been updated to reflect the use of
> both record types to illustrate usage. In all cases the TXT and SPF
> RRs are shown with a comment line between containing the word AND as
> a reminder of the current policy recommendation. It is safe to assume
> for the foreseeable future that only using a TXT version of the SPF
> will always work.

This is a wealth of information and highly appreciated, thank you. At
the moment my service provider does not support the usage of SPF
records, so for the time being I will stick to TXT, and keep an eye out
for SPF RR.

[Titanus Eramius]

On Fri, 05 Oct 2012 17:17:49 +0200
[hidden email] wrote:

>
> Zitat von Reindl Harald <[hidden email]>:
>
> > Am 05.10.2012 16:04, schrieb [hidden email]:
> >>
> >> Zitat von Titanus Eramius <[hidden email]>:
> >>
> >>> Slightly off topic. I hope it's OK when the mail is marked as
> >>> such.
> >>>
> >>> I was just wondering if the users of this list use SPF in any
> >>> way, and if so, to what extend?
> >>
> >> We have considered SPF some five years ago but after second
> >> thought ditched it completely:
> >>
> >> - It dos not really help against spam because the spam-farms also  
> >> can set proper SPF
> >
> > this point is simply wrong
> >
> > a spam-farm CAN NOT set a SPF that whatever ip is allowed
> > to send mails with my envelope - simply because they are not
> > the dns-admin of my zones
> >
> >
> > SPF is NOT a spam-protection
> >
> > it is designed to prevent forged sender-addresses which in
> > the worst case results in multiple auto-replies between
> > completly univolved persons which may over-react and
> > start blacklisting servers which are not the root-cause
> >
> > the real problem is that not EVERY domain has SPF records
> > and that is why it doe snot help as much as it could, you
> > are part of this problem because ANYBODY can send me spam
> > with yur sender-address and only blacklists and bayesian
> > filters prevents my server to send you auto-replies for
> > such messages if i am at vacation
>
> This is your opinion. Mine is i don't care what sender-addresses
> spam has but i care about preventing spam from reaching end users.
> The most spam we see are from well connected spam-farms with their
> own throw-away domains and proper SPF/DKIM set. So no, SPF/DKIM is
> not useful for us in any way but certainly you are free to use it the
> way you like and as long as you like.
>
> Regards
>
> Andreas
>

As a newcomer to both this list and Postfix in general, I did'nt
realize this subject could be "touchy", and I don't hope my question
has been seen as an attempt to stir the dam.

I'm asking out of a real world exampel from the other day, where I was
emailed by the support of a company, I had phoned and asked for some
details of a product earlier on. Since the email contained some
sensitive information I wanted to make sure, at the very least, that
the mail actually came from one of their servers, and in the past I
have checked the SPF-header of the mail.

And before you say it, I know SPF in itself is not enough to
verify an email, but it should be (IMHO) enough to ensure the email is
not spam or something similar.

All your replies have reaised a couple of questions I was hoping could
be answered as well.

* As far as I understand, it should then be safe to drop mails with a
  SPF that does not match? I know this is not a antispam policy, for
  that I use rules in "smtpd_recipient_restrictions".

* Is there any advantage in using "v=spf1 ip4:1.2.3.4 -all" compared
  to "v=spf1 mx -all" or the other way around?

[Wietse Venema]

Titanus Eramius:
> And before you say it, I know SPF in itself is not enough to
> verify an email, but it should be (IMHO) enough to ensure the email is
> not spam or something similar.

OK. That's enough nonsense. I am stopping this thread on punishment
of removal.  For questions about SPF, go to some other mailing list.

        Wietse

[Reindl Harald-2]

Am 06.10.2012 22:37, schrieb Titanus Eramius:
> * Is there any advantage in using "v=spf1 ip4:1.2.3.4 -all" compared
> to "v=spf1 mx -all" or the other way around?

"v=spf1 mx -all" enforces a additional dns-request
while "v=spf1 ip4:1.2.3.4 -all" does not

[Benny Pedersen]

Robert Schetterer skrev den 05-10-2012 17:01:

> i use policyd-spf-perl

here i use sid-milter

> only selective for some domains

why ?

> doesnt help very much, spammers have most valid spf

the only valid domain is the one senders is sending with ?

> and setup all "my domains" with spf non strict
> helps little for backscatter and may help deliver in at big mail
> providers

i have seen bankdomains with softfails, not a big deal :)

> as spf breaks forwarding it should be avoided, dont use it if you
> dont
> have to, use dkim

spf does not break forwarding, admins breaks what spf does, if you
belive spf is breaking forwarding then see the specs one more time, but
i agre if sender-id is enforced then its right that it breaks forwarding

but its incorrect to blame spf for sender-id problems

[Benny Pedersen]

> We have considered SPF some five years ago but after second thought
> ditched it completely:

it helps nothing to not using it

> - It dos not really help against spam because the spam-farms also can
> set proper SPF

and it thats the problem one can block such domains in mta as sender
check, not a big deal

> - It is not really useful for prove-of-sender because no MUA care
> about

inccorect, if headers exists, then webmail can show results from this
test

> - It does not add any aditional security/reliability to e-mail

inccorrect

> - There are problems with forwarding

show example ?

> Instead we have installed a S/MIME Gateway which solve the
> prove-of-sender with additional benefits of making encrypted mail
> possible.

correct, its more what you want, but saying spf breaks or is not
usefull is not correct, it is usefull if used correct, to the question
that senders can add valid spf, and still send spam, then block that
sender domain is still possible even if the sender is not using spf

> But as always YMMV

you have removed your real name in mua so roundcube using your email as
sender in body as failback, i remove it :)