subject:"Off Topic \- SPF \- What a Disaster"

On 25.02.10 15:22, Marc Perkel wrote:
 I'd like to find a way to get people to get their FCrDNS correct. The  
 way I see it if they can't get RDNS correct they aren't going to get SPF  
 correct. Unfortunately I get a lot of ham from IPs with no RDNS.

fcrdns can't be used to filter spam because many spammers use ir properly.

-- 
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
The early bird may get the worm, but the second mouse gets the cheese.

Re: Off Topic - SPF - What a Disaster

On 25.02.10 17:08, Marc Perkel wrote:
 The forward issue is definitely an annoyance. But SPF has a problem in  
 that as the supporters admit, it doesn't block spam, and it can't be  
 used as a white rule because spammers often use SPF correctly. 

Marc, why are YOU trolling?

Are you attempting to say that whitelisting on IPs can't be used because
spammers use IPs correctly?

-- 
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I drive way too fast to worry about cholesterol.

Re: Off Topic - SPF - What a Disaster

 LuKreme wrote:
 Here's where spf is useful. 

On 25.02.10 15:31, Marc Perkel wrote:
 Except that it breaks forwarded email.

I have never seen any occurence of SPF breaking forwarding.

But if you forward e-mail from someone and you are pretending to be him,
we may reject it because you are forging.
-- 
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I intend to live forever - so far so good.

Re: Off Topic - SPF - What a Disaster

2010-02-26 Thread Per Jessen

Matus UHLAR - fantomas wrote:

 LuKreme wrote:
 Here's where spf is useful.
 
 On 25.02.10 15:31, Marc Perkel wrote:
 Except that it breaks forwarded email.
 
 I have never seen any occurence of SPF breaking forwarding.

Really?  Do you know which problem SRS was meant to address then?  If
SPF doesn't break forwarding, surely we have no need for SRS.


/Per Jessen, Zürich

Re: Off Topic - SPF - What a Disaster

  LuKreme wrote:
  Here's where spf is useful.
  
  On 25.02.10 15:31, Marc Perkel wrote:
  Except that it breaks forwarded email.

 Matus UHLAR - fantomas wrote:
  I have never seen any occurence of SPF breaking forwarding.

On 26.02.10 09:46, Per Jessen wrote:
 Really?  Do you know which problem SRS was meant to address then?  If
 SPF doesn't break forwarding, surely we have no need for SRS.

I have explained it many times, even in the mail you quote.
I don't see reason to repeat that to people who can't / don't want to
understand.

The funniest anti-SPF anti-SRS argument at
http://david.woodhou.se/why-not-spf.html
was the alternative SES which was inspired by SRS.
-- 
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
If Barbie is so popular, why do you have to buy her friends?

Re: Off Topic - SPF - What a Disaster

2010-02-26 Thread Mike Cardwell


On 25/02/2010 23:31, Marc Perkel wrote:


As someone who forwards email what I see is this.

Sender has restrictive SPF.
Recipient server enforces SPF.
Mail coming through me bounces.

Then they call me to complain and I say, I didn't bounce it. Get rid of
your SPF nd your email will be received.


In your scenario, there are two broken systems. Neither of which are SPF.

The first broken system is your user. They've applied SPF to their 
domain. They've set up mail forwarding from your service. Yet they still 
apply SPF checking against your servers? That is stupid. They've 
misconfigured their mail service. They should either remove SPF, get rid 
of the forwarding, or change the forwarding provider to one which 
rewrites the envelope sender.


The second broken system is your forwarding system. It's is forging the 
envelope sender instead of correctly rewriting it. Fix that, or continue 
to offer a sub-standard forwarding service. Your choice.


It's not SPF's fault that your clueless user can't receive some email. 
It's a combination of your broken forwarding configuration, and your 
clueless users misconfiguration of their email.


It's too late anyway. Your opinion is no longer relevant. SPF is 
absolutely here to stay. It is supported by *many* large providers, and 
a large proporition of ham is already using SPF.


Ideally, 100% of Ham and 100% of Spam would use SPF. You don't seem to 
get this though. You think SPF is only useful if 100% of Ham uses it and 
0% of Spam uses it. That's a flaw in your understanding of what it's 
there for.


If a Spam comes from example.com and it's SPF protected, then you know 
the domain hasn't been forged, and it's safe to blacklist it. If it 
*isn't* SPF protected, then for all you know it has been forged and 
blacklisting it might cause collateral damage.


The positive aspects of *any* mail being signed with SPF, ham *or* 
spam, are so damn obvious, I don't know how you manage to mis-represent 
them so blatantly and so poorly.


--
Mike Cardwell: UK based IT Consultant, Perl developer, Linux admin
Cardwell IT Ltd. : UK Company - http://cardwellit.com/   #06920226
Technical Blog   : Tech Blog  - https://secure.grepular.com/
Spamalyser   : Spam Tool  - http://spamalyser.com/

RE: Off Topic - SPF - What a Disaster

2010-02-26 Thread Rick Cooper

Original Message
From: Marc Perkel [mailto:m...@perkel.com]
Sent: Thursday, February 25, 2010 6:11 PM
To: Rick Cooper
Cc: 'ram'; users@spamassassin.apache.org
Subject: Re: Off Topic - SPF - What a Disaster

 Rick Cooper wrote:

   The anti-SPF bandwagon is not ego driven but results driven. Than
  you  for admitting that SPF in not a spam filtering solution.
  However it  is also not a white listing solution because as many
  people have said  here - spammers are the ones who are using SPF
  correctly. I can see  some theoretical benefits that if you have a
  list of banks with SPF  and you receive an email from an address
  that the bank lists then you  can safely pass it. But I find that an
  easier way to do that is to  use FCrDNS to do the same thing.

   On the down site SPF breaks email forwarding and it creates a false
   sense that people are doing something to fight spam or protect ham
   that is not supported by reality. SPF has received intellectual
   welfare because stuff that doesn't work tends to be culled out of
   spam assassin and other than backscatter most people here are
  telling  the SPF supporters that it doesn't work. If SPF is becoming
  more  popular it just means that more people are misled.

 So then SRS Doesn't work for forwarding systems? I ask because I am
 not a forwarding service and, as I only handle corporate mail
 systems, do not give access to arbitrary forwarding to the mail
 users so we do not have tons of (external) forwarding going on. Since
 SPF and SRS are like legs on the same body I will assume trying to walk
 with 
 one leg produces results similar to a forwarding service using SPF
 without SRS. I personally would love comcast would list all of their
 Valid outbound mail hosts and hard fail all others, same with aol,
 yahoo, gmail, etc. Seems to me if you are going to push email all over
 hell's half acre it behooves you To use any and all tools available to
 take responsibility for those mails and SPF is One of several tools that
 can do that, at least to some extent. If there would have been Some kind
 of total commitment to spam 10 years ago we would not be where we are
 today and Spamassassin (as it is) would not be quite so necessary. 

 (My apologies for the pathetic attempt at manually reformatting
 the original html post)

 SRS is even more broken than SPF. I allow users to white list or black
 list based on the sender. If you rewrite the sender then you lose sender
 based conditionals. SRS has no use other than to try to fix SPF which
 has no use in the first place.

I suppose you would have to add logic to your whitlisting to accommodate an
SRS message, it's not like you cannot tell and the return path remains
intact so the original sending address is still available for the white
list. Pobox.com uses it (of course) and the are a forwarding service. I
don't personally see SPF as a spam tool so much as someone taking
responsibility for the mail they send. I suppose since all forwarding
services are legitimate the world should just take messages originating from
them as legitimate as well My bad

Rick

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Re: Off Topic - SPF - What a Disaster


On 25-Feb-2010, at 18:08, Marc Perkel wrote:


it doesn't block spam,


But as I said the absence of SPF can be used to block the most harmful  
and risky of spams.


and it can't be used as a white rule because spammers often use SPF  
correctly.



It can't be used INDISCRIMINATELY as a whitelist.

One cannot say, hey, this random message from someone I never heard  
of passes SPF, it must be OK.


One CAN say hey, this email from {bob, mom, the bank, ebay, paypal,  
dell, microsoft} passes SPF, it must be ok.


In SA terms

SPF_PASS 0.001
SPF_fail 5.0

--
(...) IT IS NOT YET MIDNIGHT?
'I shouldn't think it's more than a quarter past eleven.'
THEN WE HAVE THREE-QUARTERS OF AN HOUR
'How can you be sure?'
BECAUSE OF DRAMA, MISS FLITWORTH.. THE KIND OF DEATH WHO POSES AGAINST  
THE SKYLINE AND GETS LIT UP BY LIGHTNING FLASHES, said Bill Door,  
disapprovingly, DOESN'T TURN UP AT FIVE-AND-TWENTY PAST ELEVEN IF HE  
CAN POSSIBLY TURN UP AT MIDNIGHT. --Reaper Man

Re: Off Topic - SPF - What a Disaster


On 26-Feb-2010, at 07:13, LuKreme wrote:

SPF_PASS 0.001
SPF_fail 5.0


whitelist_from_spf *...@ebay.com
whitelist_from_spf *...@paypal.com

--
I WILL NOT AIM FOR THE HEAD
Bart chalkboard Ep. 8F13

Re: Off Topic - SPF - What a Disaster

2010-02-26 Thread Mike Cardwell


On 26/02/2010 14:20, LuKreme wrote:

On 26-Feb-2010, at 07:13, LuKreme wrote:

SPF_PASS 0.001
SPF_fail 5.0


whitelist_from_spf *...@ebay.com
whitelist_from_spf *...@paypal.com


You forgot whitelist_from_spf *...@*.apache.org

--
Mike Cardwell: UK based IT Consultant, Perl developer, Linux admin
Cardwell IT Ltd. : UK Company - http://cardwellit.com/   #06920226
Technical Blog   : Tech Blog  - https://secure.grepular.com/
Spamalyser   : Spam Tool  - http://spamalyser.com/

Re: Off Topic - SPF - What a Disaster


On 25-Feb-2010, at 17:48, Lee Dilkie wrote:
One of the problems is that in SA, an SPF_FAIL (hard) doesn't score  
much
above a SPF_SOFTFAIL but in my view it should. If an admin has made  
the

effort to setup a hardfail record, it should be trusted.



There are far too many incompetent admins to trust them to the  
detriment of user's real, valid emails.


SA's scores are based on real world testing, but you are free to set  
hard fail scores however you want.


--
HIGH EXPLOSIVES AND SCHOOL DON'T MIX
Bart chalkboard Ep. 8F03

Re: Off Topic - SPF - What a Disaster




Jason Bertoch wrote:

On 2/25/2010 8:08 PM, Marc Perkel wrote:


The forward issue is definitely an annoyance. But SPF has a problem 
in that as the supporters admit, it doesn't block spam, and it can't 
be used as a white rule because spammers often use SPF correctly. I'm 
not sure what you mean that forwarding has been depricated. Lots of 
people forward email for a lot of different reasons. I don't 
understand what you mean.




SPF wasn't meant to block spam, please stop asserting that.  It may 
prove useful as part of an overall spam fighting solution, but that's 
not the point of the original design.  Just as FCrDNS has proven to be 
a useful tool in spam fighting, it was never intended to be used that 
way either.  Off-site forwarding has been deprecated, mostly due to 
spam fighting methods, but for many other good reasons too.


Every modern mail solution allows an account holder to pop/imap to 
another account to pull in mail from somewhere else.  Forwarding only 
assists the lazy and breaks spam filtering.  If there wasn't another 
option, sure, off-site forwarding would still be 
needed/wanted/required.  That's just not the case anymore, and 
fighting it causes greater loss of service than adopting it.  Spam 
filtering is simply more important than handling the exception cases 
where someone refuses to pull in mail from somewhere else.


I understand this doesn't match the design of your service, but that 
doesn't make SPF wrong for the reasons you state.  Off-site forwarding 
is old technology and old thinking.  Solutions exist to fix your 
problem, as I stated previously.   SPF may break forwarding, but 
forwarding breaks spam filtering...and what's more important when 
there's already a plethora of solutions to deal with forwarding?


/out



So why would I want to break email forwarding for SPF?

Then there's the reality disconnect. You said:

SPF *wasn't meant to block spam*, please stop asserting that.  It may 
prove useful as part of an overall *spam fighting solution*, but that's 
not the point of the original design.


Seems like a contradiction.

And - SPF was originally introduced as a spam fighting solution. But 
they backed off when it was clear that it didn't fight spam.

Re: Off Topic - SPF - What a Disaster




Matus UHLAR - fantomas wrote:

On 25.02.10 15:22, Marc Perkel wrote:
  
I'd like to find a way to get people to get their FCrDNS correct. The  
way I see it if they can't get RDNS correct they aren't going to get SPF  
correct. Unfortunately I get a lot of ham from IPs with no RDNS.



fcrdns can't be used to filter spam because many spammers use ir properly.

  


I use FCRDNS mostly for whitelisting. If FCRDNS is good and it is listed 
in my lists of 14k host names then it sails through without checking.

Re: Off Topic - SPF - What a Disaster




Matus UHLAR - fantomas wrote:

LuKreme wrote:


Here's where spf is useful.
  

On 25.02.10 15:31, Marc Perkel wrote:
  

Except that it breaks forwarded email.



  

Matus UHLAR - fantomas wrote:


I have never seen any occurence of SPF breaking forwarding.
  


On 26.02.10 09:46, Per Jessen wrote:
  

Really?  Do you know which problem SRS was meant to address then?  If
SPF doesn't break forwarding, surely we have no need for SRS.



I have explained it many times, even in the mail you quote.
I don't see reason to repeat that to people who can't / don't want to
understand.

The funniest anti-SPF anti-SRS argument at
http://david.woodhou.se/why-not-spf.html
was the alternative SES which was inspired by SRS.
  


You can keep repeating it be you are still dead wrong. The SPF people 
don't get it. You act line using the original sender is prohibited and 
SRS is normal. That's your parallel universe. In the real world using 
the orinial sender is norman and SRS is mangling.

Re: Off Topic - SPF - What a Disaster




Jason Bertoch wrote:


SPF wasn't meant to block spam, please stop asserting that.


http://old.openspf.org/howworks.html

Quoting the page:

And as a user, SPF can help you sort the good from the bad. Reject mail 
that fails an SPF check.

Re: Off Topic - SPF - What a Disaster

2010-02-26 Thread Benny Pedersen


On Fri 26 Feb 2010 06:50:12 PM CET, Marc Perkel wrote
And - SPF was originally introduced as a spam fighting solution. But  
they backed off when it was clear that it didn't fight spam.


alot of lies out there


--
xpoint http://www.unicom.com/pw/reply-to-harmful.html

Re: Off Topic - SPF - What a Disaster

2010-02-26 Thread Joseph Brennan



Jason Bertoch ja...@i6ix.com wrote:


Every modern mail solution allows an account holder to pop/imap to
another account to pull in mail from somewhere else.



But this introduces a security hole, where the password to an account
on System A is stored on System B.  Forwarding avoids that.

Joseph Brennan
Columbia University Information Technology

Re: Off Topic - SPF - What a Disaster


On 26-Feb-10 11:24, Marc Perkel wrote:

Jason Bertoch wrote:

SPF wasn't meant to block spam, please stop asserting that.


http://old.openspf.org/howworks.html

Quoting the page:

And as a user, SPF can help you sort the good from the bad. Reject mail
that fails an SPF check.


And? that's what I use it for. that's what it's good for. I reject mail 
that claims to be from paypal that fails SPF. (well, I score it high 
enough that it amounts to the same thing).


You know, my car is very useful for getting groceries. The car was not 
designed with the intent of getting groceries, and no number of trips to 
the grocery store in a car will ever change that fact. Even though my 
car's *primary* use is hauling groceries, it is still not a 'grocery 
hauler device'.


--
The real American folksong is a rag -- a mental jag
A rhythmic tone for the chronic blues

Re: Off Topic - SPF - What a Disaster

2010-02-26 Thread Charles Gregory


On Fri, 26 Feb 2010, Benny Pedersen wrote:

On Fri 26 Feb 2010 06:50:12 PM CET, Marc Perkel wrote

And - SPF was originally introduced as a spam fighting solution.

alot of lies out there


Okay, this is getting stupid. Everyone on this thread, go to:

 http://www.openspf.org/Introduction

Spammers are explicitly identified as one of the problems addressed.
And even if this were somehow a 'lie', the original intent of the authors 
does not change whether SPF is *effective* for a given role. So this 
petulant arguing over its purpose is. (ad hominems snipped).


Take it off list, PLEASE.

- C

Re: Off Topic - SPF - What a Disaster

2010-02-26 Thread Benny Pedersen


On Thu 25 Feb 2010 10:31:16 PM CET, Kai Schaetzl wrote

I don't know to what you disagree, but SPF is not an anti-spam tool. Full
stop.


oh so what is spf then ?


--
xpoint http://www.unicom.com/pw/reply-to-harmful.html

Re: Off Topic - SPF - What a Disaster

2010-02-25 Thread RW

On Thu, 25 Feb 2010 12:55:50 +0530
ram r...@netcore.co.in wrote:

 On Tue, 2010-02-23 at 18:33 -0800, Marc Perkel wrote:

  I agree. I've been in the spam filtering business for many years
  and have yetto find any use for SPF at all. It's disturbing this
  useless technology is getting the false positive support we are
  seeing.
  
 Marc,
 This is just to repeat the cliche. SPF was not designed to help *you*
 in *spam filtering*. This was designed to help legitimate senders send
 mails. 

Just because it's a cliche doesn't mean it's true:


From the SPF FAQ:

   What is SPF and why is it complicating my life?

Sender Policy Framework (SPF) is an attempt to control forged
e-mail. SPF is not directly about stopping spam – junk email. It is
about giving domain owners a way to say which mail sources are
legitimate for their domain and which ones aren't. While not all
spam is forged, virtually all forgeries are spam. SPF is not
anti-spam in the same way that flour is not food: it is part of the
solution.

SPF was created in 2003 to help close loopholes in email delivery
systems that allow spammers to “spoof” or steal your email address
to send hundreds, thousands or even millions of emails illicitly.

Re: Off Topic - SPF - What a Disaster

2010-02-25 Thread Kai Schaetzl

Marc Perkel wrote on Thu, 25 Feb 2010 09:29:48 -0800:

 The anti-SPF bandwagon is not ego driven but results driven. Than you 
 for admitting that SPF in not a spam filtering solution. However it is 
 also not a white listing solution because as many people have said here 
 - spammers are the ones who are using SPF correctly.

You make the same mistake again. 
SPF is for assuring that mail with a certain sender domain was sent from a 
mailserver that is allowed to send mail for that domain. Nothing more, 
nothing less. 
It's for instance often used to have mail bypass greylisting as it doesn't 
make sense to greylist mail from an apparent mailserver.
This has nothing to do with spam. Certain combinations of SPF results and 
other stuff may typically indicate a spam or ham, but in general you just 
get a validation if that server was allowed to send. That is, by 
definition, whitelisting. If SPF was adapted 99% (and always strict with 
no allowance of not-listed servers), then you could also do blacklisting 
based on this. Still, this doesn't mean that you can use it for bland-and
-white spam-filtering. You could just reject *some* spam (that is now 
rejected by RBLs and access lists, anyway).
The only problem here is that a loose SPF definition can include all 
servers. To allow this was a big mistake. If someone doesn't want to 
restrict themselves to a certain range of servers, then they shouldn't use 
SPF.


Kai

-- 
Get your web at Conactive Internet Services: http://www.conactive.com

RE: Off Topic - SPF - What a Disaster

2010-02-25 Thread Rick Cooper


 From: Marc Perkel [mailto:m...@perkel.com] Sent: Thursday, February
 25, 2010 12:30 PM To: ram Cc: users@spamassassin.apache.org Subject:
  Re: Off Topic - SPF - What a Disaster




  ram wrote:

   On Tue, 2010-02-23 at 18:33 -0800, Marc Perkel wrote:
 
  
 Jeff Koch wrote:
  

 In an effort to reduce spam further we tried implementing SPF
 enforcement. Within three days we turned it off. What we found was
 that:
  
 - domain owners are allowing SPF records to be added to their zone
 files without understanding the implications or that are just not
 correct - domain owners and their employees regularly send email from
 mailservers that violate their SPF. - our customers were unable to
 receive email from important business contacts - our customers were
 unable to understand why we would be enforcing a system that
 prevented them from getting important email. - our customers couldn't
 understand what SPF does. - our customers could not explain SPF to
 their business contacts who would have had to contact their IT people
 to correct the SPF records.
  
 Our assessment is that SPF is a good idea but pretty much unworkable
 for an ISP/host without a major education program which we neither
 have the time or money to do. Since we like our customers and they
 pay the bills it is now a dead issue.
  
 Any other experiences? I love to hear.
   


 Best Regards,
   
 Jeff Koch, Intersessions
 
  
  
  I agree. I've been in the spam filtering business for many years and
  have yetto find any use for SPF at all. It's disturbing this useless
  technology is getting the false positive support we are seeing.


  
   Marc, This is just to repeat the cliche. SPF was not designed to help
   *you* in *spam filtering*. This was designed to help legitimate
   senders send mails.

   However as much as you, unreasonably , dislike it .. SPF adoption is
   on the rise.Two years ago most banks in India had no SPF records.
   Today almost every bank here publishes a SPF record. And that helps.
   For eg I use SPF checks to whitelist all local banks mail.

   Conversely, I have a custom rule that says if the header-from
   contains $popularbank.com and mail did not SPF pass add a score of
   3.0. Phishers can use whatever envelope from they want. But if they
   put the banks domain in the header-from the mail will be caught as
   spam. I know there are ways to get around this rule too but in
   practical life this has been real effective against phishing.


  IMHO most of the anti-SPF bandwagon is more due ego issues than
  technical.


  
 
  The anti-SPF bandwagon is not ego driven but results driven. Than you
  for admitting that SPF in not a spam filtering solution. However it
  is also not a white listing solution because as many people have said
  here - spammers are the ones who are using SPF correctly. I can see
  some theoretical benefits that if you have a list of banks with SPF
  and you receive an email from an address that the bank lists then you
  can safely pass it. But I find that an easier way to do that is to
  use FCrDNS to do the same thing.
 
  On the down site SPF breaks email forwarding and it creates a false
  sense that people are doing something to fight spam or protect ham
  that is not supported by reality. SPF has received intellectual
  welfare because stuff that doesn't work tends to be culled out of
  spam assassin and other than backscatter most people here are telling
  the SPF supporters that it doesn't work. If SPF is becoming more
  popular it just means that more people are misled.
 
So then SRS Doesn't work for forwarding systems? I ask because I am
not a forwarding service and, as I only handle corporate mail
systems, do not give access to arbitrary forwarding to the mail
users so we do not have tons of (external) forwarding going on. Since SPF
and
SRS are like legs on the same body I will assume trying to walk with
one leg produces results similar to a forwarding service using SPF
without SRS. I personally would love comcast would list all of their
Valid outbound mail hosts and hard fail all others, same with aol, yahoo,
gmail, etc.
Seems to me if you are going to push email all over hell's half acre it
behooves you
To use any and all tools available to take responsibility for those mails
and SPF is
One of several tools that can do that, at least to some extent. If there
would have been
Some kind of total commitment to spam 10 years ago we would not be where we
are today and
Spamassassin (as it is) would not be quite so necessary.

(My apologies for the pathetic attempt at manually reformatting
the original html post)


  I am open to and interested

Re: Off Topic - SPF - What a Disaster

2010-02-25 Thread Per Jessen

Marc Perkel wrote:

 I can see some theoretical benefits that if you have a list of banks
 with SPF and you receive an email from an address that the bank lists
 then you can safely pass it. But I find that an easier way to do that
 is to use FCrDNS to do the same thing.

Not a theoretical benefit, whitelist_from_spf works very well, I just
don't get to use it very often.  IMO it also requires a little less
effort than whitelist_from_rcvd. 


/Per Jessen, Zürich

Re: Off Topic - SPF - What a Disaster

2010-02-25 Thread Jeff Koch


At 02:31 PM 2/25/2010, you wrote:

Marc Perkel wrote on Thu, 25 Feb 2010 09:29:48 -0800:

 The anti-SPF bandwagon is not ego driven but results driven. Than you
 for admitting that SPF in not a spam filtering solution. However it is
 also not a white listing solution because as many people have said here
 - spammers are the ones who are using SPF correctly.

You make the same mistake again.
SPF is for assuring that mail with a certain sender domain was sent from a
mailserver that is allowed to send mail for that domain. Nothing more,
nothing less.
It's for instance often used to have mail bypass greylisting as it doesn't
make sense to greylist mail from an apparent mailserver.
This has nothing to do with spam. Certain combinations of SPF results and
other stuff may typically indicate a spam or ham, but in general you just
get a validation if that server was allowed to send. That is, by
definition, whitelisting. If SPF was adapted 99% (and always strict with
no allowance of not-listed servers), then you could also do blacklisting
based on this. Still, this doesn't mean that you can use it for bland-and
-white spam-filtering. You could just reject *some* spam (that is now
rejected by RBLs and access lists, anyway).
The only problem here is that a loose SPF definition can include all
servers. To allow this was a big mistake. If someone doesn't want to
restrict themselves to a certain range of servers, then they shouldn't use
SPF.


Kai


I disagree. SPF is just one of the tools - among other tools (e.g. DKIM, 
domain keys, not accepting email from servers with no RDNS, etc) - 
developed to help reduce spam.



--
Get your web at Conactive Internet Services: http://www.conactive.com


Best Regards,

Jeff Koch, Intersessions

Re: Off Topic - SPF - What a Disaster

2010-02-25 Thread LuKreme

On 25-Feb-2010, at 10:29, Marc Perkel wrote:
 
 The anti-SPF bandwagon is not ego driven but results driven. Than you for 
 admitting that SPF in not a spam filtering solution. However it is also not a 
 white listing solution because as many people have said here - spammers are 
 the ones who are using SPF correctly.

If you blindly accept any email with a valid spf as being 'good' email then 
your not understanding the system.

Here's where spf is useful. You have an emailer (a bank, a company, aol, 
hotmail, whatever) that is a frequent target of spoofing. You can either spend 
a lot of time and resources trying to catch the spoof emails while not trashing 
the real ones, or you can enable spf.

So, if an email comes in to my mailspool from paypal.com and it passes spf, it 
is treated as a normal message. It still goes through SA. But if it comes in 
from paypal.com and DOESN'T pass spf, it instantly gets 5 points added to it 
because if it's claiming to be from paypal AND it fails SPF, it is *not* from 
paypal.

So, while SPF is *not* an anti-spam tool, in the case of paypal, and ebay, and 
citibank (but not the mentally challenged lemurs at bankofamerica) the *lack* 
of SPF become an anti-spam tool (more often a anti-phishing tool, really).

How any mailadmin can think this is a bad thing is staggering.

  I can see some theoretical benefits that if you have a list of banks with 
 SPF and you receive an email from an address that the bank lists then you can 
 safely pass it. But I find that an easier way to do that is to use FCrDNS to 
 do the same thing.

Which fails when you have someone that has multiple domains that may be sending 
mail from the same organization. Mail to me from Citi may comes from any one 
of at least 6 different domains, and the mailserver is not necessarily in the 
same domain.
 
 On the down site SPF breaks email forwarding

uh huh. For certain values of breaks and forwarding. Resend the message as 
a rfc2822 attachment and... zomg, nothing is broken. Recipient gets the 
original unaltered message and the SMTP process doesn't have to lie about who 
the sender of the message is. But that takes some degree of effort on the part 
of mailserver, so it is widely ignored as it would constitute work.

Also, keep in mind that SPF has THREE states. Pass, fail, soft fail.

$ dig kreme.com txt +short
v=spf1 mx include:covisp.net ~all

only my mx server or the specific domain covisp.net is allowed to send email 
'from' my domain. No other host sending mail from my domain is to be considered 
valid.

I could do, instead:

v=spf1 mx include:covisp.net ?all

This means, hey, my mx server or any machine at this domain will send mail for 
me. If the email comes from there, SPF passes, but if it DIDN'T come from 
there, it might still be me, so only do a soft fail. because sometimes I route 
my mail out over gmail, or my friend ziggy.tld.

Many admins will reject both fail and soft-fail as failures, which is wrong.

 and it creates a false sense that people are doing something to fight spam or 
 protect ham that is not supported by reality. SPF has received intellectual 
 welfare because stuff that doesn't work tends to be culled out of spam 
 assassin and other than backscatter most people here are telling the SPF 
 supporters that it doesn't work. If SPF is becoming more popular it just 
 means that more people are misled.

SPF is becoming more popular because it is *effective* at what it does.

Currently I only use SPF within SA checks because it makes it trivial to catch 
most of the phishing scams.

-- 
They say only the good die young. If it works the other way too 
I'm immortal

Re: Off Topic - SPF - What a Disaster

2010-02-25 Thread Kai Schaetzl

Jeff Koch wrote on Thu, 25 Feb 2010 15:08:46 -0500:

 I disagree.

I don't know to what you disagree, but SPF is not an anti-spam tool. Full 
stop.

Kai

-- 
Get your web at Conactive Internet Services: http://www.conactive.com

Re: Off Topic - SPF - What a Disaster

2010-02-25 Thread Jeff Koch



How silly. That's like saying an iPhone is not a gaming device even though 
plenty of people use it to play game apps. Perhaps you should re-read the 
SPF FAQ's.



At 04:31 PM 2/25/2010, you wrote:

Jeff Koch wrote on Thu, 25 Feb 2010 15:08:46 -0500:

 I disagree.

I don't know to what you disagree, but SPF is not an anti-spam tool. Full
stop.

Kai

--
Get your web at Conactive Internet Services: http://www.conactive.com


Best Regards,

Jeff Koch, Intersessions

Re: Off Topic - SPF - What a Disaster




Rick Cooper wrote:
 
  The anti-SPF bandwagon is not ego driven but results driven. Than you

  for admitting that SPF in not a spam filtering solution. However it
  is also not a white listing solution because as many people have said
  here - spammers are the ones who are using SPF correctly. I can see
  some theoretical benefits that if you have a list of banks with SPF
  and you receive an email from an address that the bank lists then you
  can safely pass it. But I find that an easier way to do that is to
  use FCrDNS to do the same thing.
 
  On the down site SPF breaks email forwarding and it creates a false

  sense that people are doing something to fight spam or protect ham
  that is not supported by reality. SPF has received intellectual
  welfare because stuff that doesn't work tends to be culled out of
  spam assassin and other than backscatter most people here are telling
  the SPF supporters that it doesn't work. If SPF is becoming more
  popular it just means that more people are misled.
 
So then SRS Doesn't work for forwarding systems? I ask because I am

not a forwarding service and, as I only handle corporate mail
systems, do not give access to arbitrary forwarding to the mail
users so we do not have tons of (external) forwarding going on. Since SPF
and
SRS are like legs on the same body I will assume trying to walk with
one leg produces results similar to a forwarding service using SPF
without SRS. I personally would love comcast would list all of their
Valid outbound mail hosts and hard fail all others, same with aol, yahoo,
gmail, etc.
Seems to me if you are going to push email all over hell's half acre it
behooves you
To use any and all tools available to take responsibility for those mails
and SPF is
One of several tools that can do that, at least to some extent. If there
would have been
Some kind of total commitment to spam 10 years ago we would not be where we
are today and
Spamassassin (as it is) would not be quite so necessary.

(My apologies for the pathetic attempt at manually reformatting
the original html post)

  


SRS is even more broken than SPF. I allow users to white list or black 
list based on the sender. If you rewrite the sender then you lose sender 
based conditionals. SRS has no use other than to try to fix SPF which 
has no use in the first place.

Re: Off Topic - SPF - What a Disaster




Kai Schaetzl wrote:

Marc Perkel wrote on Thu, 25 Feb 2010 09:29:48 -0800:

  
The anti-SPF bandwagon is not ego driven but results driven. Than you 
for admitting that SPF in not a spam filtering solution. However it is 
also not a white listing solution because as many people have said here 
- spammers are the ones who are using SPF correctly.



You make the same mistake again. 
SPF is for assuring that mail with a certain sender domain was sent from a 
mailserver that is allowed to send mail for that domain. Nothing more, 
nothing less. 
It's for instance often used to have mail bypass greylisting as it doesn't 
make sense to greylist mail from an apparent mailserver.
This has nothing to do with spam. Certain combinations of SPF results and 
other stuff may typically indicate a spam or ham, but in general you just 
get a validation if that server was allowed to send. That is, by 
definition, whitelisting. If SPF was adapted 99% (and always strict with 
no allowance of not-listed servers), then you could also do blacklisting 
based on this. Still, this doesn't mean that you can use it for bland-and
-white spam-filtering. You could just reject *some* spam (that is now 
rejected by RBLs and access lists, anyway).
The only problem here is that a loose SPF definition can include all 
servers. To allow this was a big mistake. If someone doesn't want to 
restrict themselves to a certain range of servers, then they shouldn't use 
SPF.



  


SPF will never be 99% adopted until it actually does something that is 
significantly useful. Using it as a white list to bypass a grey list 
isn't what I would call significantly useful. SPF fails the actually 
works test.

Re: Off Topic - SPF - What a Disaster




Jeff Koch wrote:

At 02:31 PM 2/25/2010, you wrote:

Marc Perkel wrote on Thu, 25 Feb 2010 09:29:48 -0800:

 The anti-SPF bandwagon is not ego driven but results driven. Than you
 for admitting that SPF in not a spam filtering solution. However it is
 also not a white listing solution because as many people have said 
here

 - spammers are the ones who are using SPF correctly.

You make the same mistake again.
SPF is for assuring that mail with a certain sender domain was sent 
from a

mailserver that is allowed to send mail for that domain. Nothing more,
nothing less.
It's for instance often used to have mail bypass greylisting as it 
doesn't

make sense to greylist mail from an apparent mailserver.
This has nothing to do with spam. Certain combinations of SPF results 
and
other stuff may typically indicate a spam or ham, but in general you 
just

get a validation if that server was allowed to send. That is, by
definition, whitelisting. If SPF was adapted 99% (and always strict with
no allowance of not-listed servers), then you could also do blacklisting
based on this. Still, this doesn't mean that you can use it for 
bland-and

-white spam-filtering. You could just reject *some* spam (that is now
rejected by RBLs and access lists, anyway).
The only problem here is that a loose SPF definition can include all
servers. To allow this was a big mistake. If someone doesn't want to
restrict themselves to a certain range of servers, then they 
shouldn't use

SPF.


Kai


I disagree. SPF is just one of the tools - among other tools (e.g. 
DKIM, domain keys, not accepting email from servers with no RDNS, etc) 
- developed to help reduce spam.




I'd like to find a way to get people to get their FCrDNS correct. The 
way I see it if they can't get RDNS correct they aren't going to get SPF 
correct. Unfortunately I get a lot of ham from IPs with no RDNS.

Re: Off Topic - SPF - What a Disaster

LuKreme wrote:

On 25-Feb-2010, at 10:29, Marc Perkel wrote:

The anti-SPF bandwagon is not ego driven but results driven. Than you for
admitting that SPF in not a spam filtering solution. However it is also not a
white listing solution because as many people have said here - spammers are the
ones who are using SPF correctly.

If you blindly accept any email with a valid spf as being 'good' email then
your not understanding the system.

Here's where spf is useful. You have an emailer (a bank, a company, aol,
hotmail, whatever) that is a frequent target of spoofing. You can either spend
a lot of time and resources trying to catch the spoof emails while not trashing
the real ones, or you can enable spf.

Except that it breaks forwarded email.

So, if an email comes in to my mailspool from paypal.com and it passes spf, it is treated
as a normal message. It still goes through SA. But if it comes in from
paypal.com and DOESN'T pass spf, it instantly gets 5 points added to it because if it's
claiming to be from paypal AND it fails SPF, it is *not* from paypal.

If the host isn't a paypal server or it hasn't passed a paypal server
then it's bounced. All paypal email comes from *.paypal.com servers.

So, while SPF is *not* an anti-spam tool, in the case of paypal, and ebay, and
citibank (but not the mentally challenged lemurs at bankofamerica) the *lack*
of SPF become an anti-spam tool (more often a anti-phishing tool, really).

How any mailadmin can think this is a bad thing is staggering.

Agreed about Bank of America being brain dead.

I can see some theoretical benefits that if you have a list of banks with SPF
and you receive an email from an address that the bank lists then you can
safely pass it. But I find that an easier way to do that is to use FCrDNS to do
the same thing.

Which fails when you have someone that has multiple domains that may be sending mail
from the same organization. Mail to me from Citi may comes from any one of at
least 6 different domains, and the mailserver is not necessarily in the same domain.

Whitelist all 6 domains.

On the down site SPF breaks email forwarding

uh huh. For certain values of breaks and forwarding. Resend the message as
a rfc2822 attachment and... zomg, nothing is broken. Recipient gets the original unaltered message
and the SMTP process doesn't have to lie about who the sender of the message is. But that takes
some degree of effort on the part of mailserver, so it is widely ignored as it would constitute
work.

Also, keep in mind that SPF has THREE states. Pass, fail, soft fail.

$ dig kreme.com txt +short
v=spf1 mx include:covisp.net ~all

only my mx server or the specific domain covisp.net is allowed to send email
'from' my domain. No other host sending mail from my domain is to be considered
valid.

I could do, instead:

v=spf1 mx include:covisp.net ?all

This means, hey, my mx server or any machine at this domain will send mail for me.
If the email comes from there, SPF passes, but if it DIDN'T come from there, it
might still be me, so only do a soft fail. because sometimes I route my mail out
over gmail, or my friend ziggy.tld.

Many admins will reject both fail and soft-fail as failures, which is wrong.

As someone who forwards email what I see is this.

Sender has restrictive SPF.
Recipient server enforces SPF.
Mail coming through me bounces.

Then they call me to complain and I say, I didn't bounce it. Get rid of
your SPF nd your email will be received.

and it creates a false sense that people are doing something to fight spam or
protect ham that is not supported by reality. SPF has received intellectual
welfare because stuff that doesn't work tends to be culled out of spam assassin
and other than backscatter most people here are telling the SPF supporters that
it doesn't work. If SPF is becoming more popular it just means that more people
are misled.

SPF is becoming more popular because it is *effective* at what it does.

Currently I only use SPF within SA checks because it makes it trivial to catch
most of the phishing scams.

I'm not hearing from people in this forum who are saying it works. Even
those who are SPF evangelists can't point to any significant results in
either blocking spam or passing ham.

Can you catch phishing without false positives from forwarding where the
forwarder does not use SRS?

Re: Off Topic - SPF - What a Disaster




Kai Schaetzl wrote:

Jeff Koch wrote on Thu, 25 Feb 2010 15:08:46 -0500:

  

I disagree.



I don't know to what you disagree, but SPF is not an anti-spam tool. Full 
stop.


Kai

  


You say that here but in your last message you said:

 If SPF was adapted 99% (and always strict with no allowance of 
not-listed servers), then you could also do blacklisting based on this.


You can't have it both ways.

Which is another problem I have with SPF evangelists is that they say 
(now) that isn't not for blocking spam. But yet people are encouraged to 
use it to block spam. Everything else proposed here has to pass the 
reality test. It has to actually work. But for SPF we are lowering the 
bar for some reason. I don't see why SA has any SPF if it doesn't do 
anything.

Re: Off Topic - SPF - What a Disaster

2010-02-25 Thread Martin Gregorie

On Thu, 2010-02-25 at 15:19 -0800, Marc Perkel wrote:

 SPF will never be 99% adopted until it actually does something that is 
 significantly useful. Using it as a white list to bypass a grey list 
 isn't what I would call significantly useful. SPF fails the actually 
 works test.

But it DOES do something useful.

It reduces backscatter from spam that uses your domain as the forged
sender. And it does so without costing you more cycles than a DNS lookup
uses.

That's it. I've said my say. I'm out of this unnecessary pissing match
after saying to the OP who gratuitously started it: May the fleas from
a thousand camels infest your armpits.


Martin

Re: Off Topic - SPF - What a Disaster

2010-02-25 Thread Lee Dilkie


Marc Perkel wrote:
 I'm not hearing from people in this forum who are saying it works.
 Even those who are SPF evangelists can't point to any significant
 results in either blocking spam or passing ham.


Well it's no magic bullet, but nothing is. I use SPF to try and make my
domain less a target for spammers to forge. I got hit with a massive
backscatter flood last week that killed my service and I changed my SPF
records to hardfail and had to notify my (few) clients to let them
know that they were now required to use my server for outgoing mail
(auth on port 587).

Only time will tell if helps. But I immediately saw the effect in the
bounce messages, domains like gmail were aware of the hardfail on their
spf check.

One of the problems is that in SA, an SPF_FAIL (hard) doesn't score much
above a SPF_SOFTFAIL but in my view it should. If an admin has made the
effort to setup a hardfail record, it should be trusted.

SPF_PASS shouldn't be trusted as far as spam processing, as we all know,
as spammers can setup valid SPF records. But it does help against
spambot's, doesn't it? It's hard to setup valid SPF records when you're
sending spam from a million infected machines.

-lee

Re: Off Topic - SPF - What a Disaster

2010-02-25 Thread Jason Bertoch


On 2/25/2010 6:37 PM, Marc Perkel wrote:


A lot of posts with useless rants on a personal grievance against SPF


Marc,

I suspect you're not seeing a bunch of supporters of SPF post on this 
thread because most find it tiresome, bothersome, pointless, or all of 
the above.  I bit my lip until now for all of those reasons, but can't 
stand your continual whining.  You're clearly only mad at SPF because of 
the forwarding issue.  As has been stated in a multitude of threads over 
the years, including this one, SPF has its place for those that use it 
in the way it was intended.


Although, I agree that FCrDNS is very useful, I'm also aware that it's 
just another tool in the box.  For some unfortunate reason, many 
providers don't allow changes to PTR records to accommodate their 
customers.  SPF provides an alternate means by which domain owners can 
publish useful mail source information on their own, regardless of 
provider cooperation/competence.


Forwarding off-site has essentially been deprecated since spam filtering 
began and the wide-spread availability of mail submission ports/relaying 
via authentication.  SPF isn't your problem, it's your ego.  If you 
proxy your connections, like the rest of your [much] bigger competitors 
do, the forwarding issue goes away.  Or, if you don't feel like coding, 
ask your customers to use the SPF include directive where you can 
publish additional allowable servers.  SPF simply isn't the problem, 
please stop whining.


/out

Re: Off Topic - SPF - What a Disaster




Jason Bertoch wrote:

On 2/25/2010 6:37 PM, Marc Perkel wrote:


A lot of posts with useless rants on a personal grievance against SPF


Marc,

I suspect you're not seeing a bunch of supporters of SPF post on this 
thread because most find it tiresome, bothersome, pointless, or all of 
the above.  I bit my lip until now for all of those reasons, but can't 
stand your continual whining.  You're clearly only mad at SPF because 
of the forwarding issue.  As has been stated in a multitude of threads 
over the years, including this one, SPF has its place for those that 
use it in the way it was intended.


Although, I agree that FCrDNS is very useful, I'm also aware that it's 
just another tool in the box.  For some unfortunate reason, many 
providers don't allow changes to PTR records to accommodate their 
customers.  SPF provides an alternate means by which domain owners can 
publish useful mail source information on their own, regardless of 
provider cooperation/competence.


Forwarding off-site has essentially been deprecated since spam 
filtering began and the wide-spread availability of mail submission 
ports/relaying via authentication.  SPF isn't your problem, it's your 
ego.  If you proxy your connections, like the rest of your [much] 
bigger competitors do, the forwarding issue goes away.  Or, if you 
don't feel like coding, ask your customers to use the SPF include 
directive where you can publish additional allowable servers.  SPF 
simply isn't the problem, please stop whining.


/out



The forward issue is definitely an annoyance. But SPF has a problem in 
that as the supporters admit, it doesn't block spam, and it can't be 
used as a white rule because spammers often use SPF correctly. I'm not 
sure what you mean that forwarding has been depricated. Lots of people 
forward email for a lot of different reasons. I don't understand what 
you mean.

Re: Off Topic - SPF - What a Disaster

2010-02-25 Thread Jason Bertoch


On 2/25/2010 8:08 PM, Marc Perkel wrote:


The forward issue is definitely an annoyance. But SPF has a problem in 
that as the supporters admit, it doesn't block spam, and it can't be 
used as a white rule because spammers often use SPF correctly. I'm not 
sure what you mean that forwarding has been depricated. Lots of people 
forward email for a lot of different reasons. I don't understand what 
you mean.




SPF wasn't meant to block spam, please stop asserting that.  It may 
prove useful as part of an overall spam fighting solution, but that's 
not the point of the original design.  Just as FCrDNS has proven to be a 
useful tool in spam fighting, it was never intended to be used that way 
either.  Off-site forwarding has been deprecated, mostly due to spam 
fighting methods, but for many other good reasons too.


Every modern mail solution allows an account holder to pop/imap to 
another account to pull in mail from somewhere else.  Forwarding only 
assists the lazy and breaks spam filtering.  If there wasn't another 
option, sure, off-site forwarding would still be 
needed/wanted/required.  That's just not the case anymore, and fighting 
it causes greater loss of service than adopting it.  Spam filtering is 
simply more important than handling the exception cases where someone 
refuses to pull in mail from somewhere else.


I understand this doesn't match the design of your service, but that 
doesn't make SPF wrong for the reasons you state.  Off-site forwarding 
is old technology and old thinking.  Solutions exist to fix your 
problem, as I stated previously.   SPF may break forwarding, but 
forwarding breaks spam filtering...and what's more important when 
there's already a plethora of solutions to deal with forwarding?


/out

Re: Off Topic - SPF - What a Disaster

2010-02-25 Thread John Hardin


On Thu, 25 Feb 2010, Marc Perkel wrote:


Jason Bertoch wrote:

 On 2/25/2010 6:37 PM, Marc Perkel wrote:
 
  A lot of posts with useless rants on a personal grievance against 
  SPF ...


 Marc,

 I suspect you're not seeing a bunch of supporters of SPF post on this
 thread because most find it tiresome, bothersome, pointless, or all of
 the above. ...

 /out


The forward issue is definitely an annoyance. But SPF has a problem in 
that as the supporters admit, it doesn't block spam, ...


Followups-To: alt.advocacy.spf.headdesk.headdesk.headdesk.headdesk.headdesk

--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  W-w-w-w-w-where did he learn to n-n-negotiate like that?
---
 139 days since President Obama won the Nobel Not George W. Bush prize

Re: Off Topic - SPF - What a Disaster

2010-02-25 Thread ram

Marc,
 
  Which fails when you have someone that has multiple domains that may be 
  sending mail from the same organization. Mail to me from Citi may comes 
  from any one of at least 6 different domains, and the mailserver is not 
  necessarily in the same domain.

 Whitelist all 6 domains.
   

What if Citi starts using mail services from another provider with a
different ptr. Do you expect them to announce that on this mailing
list ? 
Conversely what if City stops services from one and then a
phisher/spammer buys of the server space. Thanks to the stupid whitelist
I will be sending all these spams whitelisted until we have angry  calls
on the customer support helpdesk.

This is useless for me to keep tracking what servers Citi ,Bank of
America, or ICICIBank  uses. I put just 1 line in my .cf file and
forget about it. Because their SPF record already keeps track. 

Even the largest banks today are outsourcing their email. FcRDNS works
only if the organization runs their own mailing and dont keep changing
their mailhost names. 


Thanks
Ram

Re: Off Topic - SPF - What a Disaster

Kelson wrote:

 SPF works great as a selective whitelist in SpamAssassin. (And I don't
 mean whitelisting all SPF passes. That would be stupid. I mean
 whitelisting mail coming from domain X, but only when it passes SPF
 and demonstrates that yes, it really came from domain X.)
 
 I'd say that what you found is *not* that SPF itself is a disaster,
 but that enforcing SPF by rejecting failures is a disaster.

+1


/Per Jessen, Zürich

Re: Off Topic - SPF - What a Disaster

LuKreme wrote:

 On 23-Feb-10 14:17, Bowie Bailey wrote:
 SPF enforcement at the MTA is useless for the reasons you specified.
 The only exception is if you have a strict SPF policy for your own
 domain, you can use it to reject spam pretending to be from your
 users.
 
 And that makes it worthwhile all by itself.
 

Well, I guess it depends on your point of view - how difficult is it to
set up an MTA to reject mails pretending to be from yourdomain that
didn't originate on your MTA?  


/Per Jessen, Zürich

Re: [SPAM:9.6] Re: Off Topic - SPF - What a Disaster

On Wed, 24 Feb 2010 09:18:38 +0100
Per Jessen p...@computer.org wrote:

 LuKreme wrote:
 
  On 23-Feb-10 14:17, Bowie Bailey wrote:
  SPF enforcement at the MTA is useless for the reasons you
  specified. The only exception is if you have a strict SPF policy
  for your own domain, you can use it to reject spam pretending to
  be from your users.
  
  And that makes it worthwhile all by itself.
  
 
 Well, I guess it depends on your point of view - how difficult is it
 to set up an MTA to reject mails pretending to be from yourdomain
 that didn't originate on your MTA?  
 
 
 /Per Jessen, Zürich
 

Good question - how would you do it?

Re: [SPAM:9.6] Re: Off Topic - SPF - What a Disaster

Christian Brel wrote:

 On Wed, 24 Feb 2010 09:18:38 +0100
 Per Jessen p...@computer.org wrote:
 
 LuKreme wrote:
 
  On 23-Feb-10 14:17, Bowie Bailey wrote:
  SPF enforcement at the MTA is useless for the reasons you
  specified. The only exception is if you have a strict SPF policy
  for your own domain, you can use it to reject spam pretending to
  be from your users.
  
  And that makes it worthwhile all by itself.
  
 
 Well, I guess it depends on your point of view - how difficult is it
 to set up an MTA to reject mails pretending to be from yourdomain
 that didn't originate on your MTA?
 
 
 /Per Jessen, Zürich
 
 
 Good question - how would you do it?

Postfix:  I would have two different smtpd daemons - one for the local
network, one for the external.  The external smtpd would have a
check_sender_access along these lines (thinking out loud here):

check_sender_access = hash:/etc/postfix/reject_from_my_domain

etc/postfix/reject_from_my_domain would have:

example.com 5xx 


/Per Jessen, Zürich

Re: [SPAM:9.6] Re: Off Topic - SPF - What a Disaster

On Wednesday, 24 of February 2010, Per Jessen wrote:
  Well, I guess it depends on your point of view - how difficult is it
  to set up an MTA to reject mails pretending to be from yourdomain
  that didn't originate on your MTA?
  Good question - how would you do it?
 
 Postfix:  I would have two different smtpd daemons - one for the local
 network, one for the external.  The external smtpd would have a
 check_sender_access along these lines (thinking out loud here):
 
 check_sender_access = hash:/etc/postfix/reject_from_my_domain
 
 etc/postfix/reject_from_my_domain would have:
 
 example.com 5xx

How's it different from the standard approach - permitting mynetworks and 
then rejecting mails from self? Two instances of postfix only make the setup 
more complicated.

-- 
/\-\/\-\/\-\/\-\/\-\/\-\/\ 
\  k...@epsilon.eu.org   / 
/ http://epsilon.eu.org/ \ 
\/-/\/-/\/-/\/-/\/-/\/-/\/

Re: [SPAM:9.6] Re: Off Topic - SPF - What a Disaster

Mariusz Kruk wrote:

 On Wednesday, 24 of February 2010, Per Jessen wrote:
  Well, I guess it depends on your point of view - how difficult is
  it to set up an MTA to reject mails pretending to be from
  yourdomain that didn't originate on your MTA?
  Good question - how would you do it?
 
 Postfix:  I would have two different smtpd daemons - one for the
 local network, one for the external.  The external smtpd would have a
 check_sender_access along these lines (thinking out loud here):
 
 check_sender_access = hash:/etc/postfix/reject_from_my_domain
 
 etc/postfix/reject_from_my_domain would have:
 
 example.com 5xx
 
 How's it different from the standard approach - permitting
 mynetworks and then rejecting mails from self? Two instances of
 postfix only make the setup more complicated.

Barely, but I think you're right, that approach works equally well.


/Per Jessen, Zürich

Re: [SPAM:9.6] Re: Off Topic - SPF - What a Disaster

On Wed, 24 Feb 2010 10:28:24 +0100
Per Jessen p...@computer.org wrote:

 Christian Brel wrote:
 
  On Wed, 24 Feb 2010 09:18:38 +0100
  Per Jessen p...@computer.org wrote:
  
  LuKreme wrote:
  
   On 23-Feb-10 14:17, Bowie Bailey wrote:
   SPF enforcement at the MTA is useless for the reasons you
   specified. The only exception is if you have a strict SPF policy
   for your own domain, you can use it to reject spam pretending to
   be from your users.
   
   And that makes it worthwhile all by itself.
   
  
  Well, I guess it depends on your point of view - how difficult is
  it to set up an MTA to reject mails pretending to be from
  yourdomain that didn't originate on your MTA?
  
  
  /Per Jessen, Zürich
  
  
  Good question - how would you do it?
 
 Postfix:  I would have two different smtpd daemons - one for the local
 network, one for the external.  The external smtpd would have a
 check_sender_access along these lines (thinking out loud here):
 
 check_sender_access = hash:/etc/postfix/reject_from_my_domain
 
 etc/postfix/reject_from_my_domain would have:
 
 example.com 5xx 
 
 
 /Per Jessen, Zürich
 


So you would reject outbound mail from your domain? I'm sure that's a
typo. The agrovation of multi-instancing Postfix onto a different port
or IP, seeking help from their aggressive and abusive user list when it
fails to work -v- SPF. Ummm such a choice.

Re: Off Topic - SPF - What a Disaster

2010-02-24 Thread Matus UHLAR - fantomas

On 23.02.10 15:38, Jeff Koch wrote:
 In an effort to reduce spam further we tried implementing SPF 
 enforcement.

You should implement SPF in order to prevent mail forgery, not spam.
SPF is a tool to reduce forgery, not spam.
The fact that most of spam has forged address only helps you.

 Within three days we turned it off. What we found was that:

You have turned it on where? In your MTA at SMTP level?
In your domain(s)? In both? And in your domain(s), hard or soft fail?

 - domain owners are allowing SPF records to be added to their zone files  
 without understanding the implications or that are just not correct

domain owners can do anything with their domains, wheter it's correct or
not.

 - domain owners and their employees regularly send email from mailservers 
 that violate their SPF.

This is a main problem we all should try to avoid. Many domains' owners e.g.
ESPs are already trying to avoid this by putting SPF and DKIM records to
their domains.

So you have turned it off? They won't be glad.

 - our customers were unable to receive email from important business contacts
 - our customers were unable to understand why we would be enforcing a  
 system that prevented
   them from getting important email.

Well, because senders' admins wish to do so.

 - our customers couldn't understand what SPF does.
 - our customers could not explain SPF to their business contacts who 
 would have had to contact their IT people to correct the SPF records.

their business contacts are apparently doing something against themselves.

 Our assessment is that SPF is a good idea but pretty much unworkable for 
 an ISP/host without a major education program which we neither have the 
 time or money to do. Since we like our customers and they pay the bills 
 it is now a dead issue.

Well, many people are admitting SPF is broken, just because others are
doing stuff (use incorrect SMTP servers, resending the mail using others'
sender addresses) which are in fact broken, not SPF.

What I understand, there should be some kind of local SPF whitelists,
allowing known broken forwarders, decreasing FAIL from hard to soft for some
domains...

I don't think that not implementing techniques because some people tend to
break things is a way to go. Forcing them to fix broken things is.

-- 
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
WinError #9: Out of error messages.

Re: Off Topic - SPF - What a Disaster

2010-02-24 Thread Matus UHLAR - fantomas

On 23.02.10 16:17, Bowie Bailey wrote:
 SPF enforcement at the MTA is useless for the reasons you specified. 
 The only exception is if you have a strict SPF policy for your own
 domain, you can use it to reject spam pretending to be from your users.

And what is this, if not enforcing SPF at MTA level?

Also, this can be solved at MTA level without SPF enforcement. Afaik some
servers are already rejecting mail from their users without proper
authentification.
-- 
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
WinError #98652: Operation completed successfully.

Re: [SPAM:9.6] Off Topic - SPF - What a Disaster

You don't have to run two postfixes for this.

Kai

-- 
Get your web at Conactive Internet Services: http://www.conactive.com

Re: [SPAM:9.6] Off Topic - SPF - What a Disaster

Kai Schaetzl wrote:

 You don't have to run two postfixes for this.
 
 Kai

I wasn't suggesting two postfixes, only two smtpds, but what Mariusz
said is even easier.


/Per Jessen, Zürich

RE: [SPAM:9.6] Off Topic - SPF - What a Disaster

2010-02-24 Thread Rob Sterenborg

On 2010-02-24, Kai Schaetzl wrote:

  Postfix:  I would have two different smtpd daemons - one for

 You don't have to run two postfixes for this.

I think Per means: 2 smtpd processes, not 2 Postfixes..


--
Rob

Re: [SPAM:9.6] Off Topic - SPF - What a Disaster

Christian Brel wrote on Wed, 24 Feb 2010 10:02:02 +:

 So you would reject outbound mail from your domain? I'm sure that's a
 typo.

He just didn't show the full configuration. It's obvious that you put your 
allowance checks first.

Kai

-- 
Get your web at Conactive Internet Services: http://www.conactive.com

Re: [SPAM:9.6] Off Topic - SPF - What a Disaster

On Wed, 24 Feb 2010 11:39:43 +0100
Rob Sterenborg r.sterenb...@netsourcing.nl wrote:

 On 2010-02-24, Kai Schaetzl wrote:
 
   Postfix:  I would have two different smtpd daemons - one for
 
  You don't have to run two postfixes for this.
 
 I think Per means: 2 smtpd processes, not 2 Postfixes..
 
 
 --
 Rob
 

Humour me. Does this not mean a need to change the outbound to either a
different IP or port? I guess you could start hashing things around
with IPTables to redirect certain requests, but once you've done all of
this, changed all the clients etc. etc, you are saying this would be
*easier* than SPF?

Sure, I get the sentiment but I don't necessarily agree that large
changes would be better than making use of a simple DNS based mechanism
that already exists. Factor in the millions of email users who
don't use Postfix and run things like Exchange and things tend to widen
up.

Re: [SPAM:9.6] Off Topic - SPF - What a Disaster

Rob Sterenborg wrote on Wed, 24 Feb 2010 11:39:43 +0100:

 I think Per means: 2 smtpd processes, not 2 Postfixes..

and I meant what he meant ;-)

Kai

-- 
Get your web at Conactive Internet Services: http://www.conactive.com

Re: [SPAM:9.6] Off Topic - SPF - What a Disaster

On Wednesday, 24 of February 2010, Per Jessen wrote:
  I guess you could start hashing things around
  with IPTables to redirect certain requests, but once you've done all
  of this, changed all the clients etc. etc, you are saying this would
  be *easier* than SPF?
 See Mariusz Kruks suggestion - that's the way to do it.  Accept
 everything from mynetworks, reject everything pretending to be coming
 from your domain.

Let's also add that you should receive mail on port 25 from other SMTP servers 
only; port 25 is not meant for endusers nowadays. So it should not (unless you 
have multiple servers and some complicated setup, but then you probably know 
what you are doing anyway) be _from_ your domain. Mail _from_ your domain 
(which means your clients) should be submitted to port 587 where you do not 
accept anything unless client authenticated himself (by SMTP-auth, being in 
apropriate IP-range or any other means).
It all makes it quite easy to _not_ accept mail from outside world which seems 
to be originating in your domain.

-- 
\/ 
|  k...@epsilon.eu.org   | 
| http://epsilon.eu.org/ | 
/\

Re: [SPAM:9.6] Off Topic - SPF - What a Disaster

Kai Schaetzl wrote:

 Christian Brel wrote on Wed, 24 Feb 2010 10:02:02 +:
 
 So you would reject outbound mail from your domain? I'm sure that's a
 typo.
 
 He just didn't show the full configuration. It's obvious that you put
 your allowance checks first.
 
 Kai

I did also say 'thinking out loud here', so yes, it was obviously not a
complete config.  However, smtpd is not involved in sending outbound
mail, so my sender access check would not get in the way.


/Per Jessen, Zürich

Re: [SPAM:9.6] Off Topic - SPF - What a Disaster

2010-02-24 Thread Henrik K

On Wed, Feb 24, 2010 at 11:30:25AM +, Christian Brel wrote:
 On Wed, 24 Feb 2010 11:39:43 +0100
 Rob Sterenborg r.sterenb...@netsourcing.nl wrote:
 
  On 2010-02-24, Kai Schaetzl wrote:
  
Postfix:  I would have two different smtpd daemons - one for
  
   You don't have to run two postfixes for this.
  
  I think Per means: 2 smtpd processes, not 2 Postfixes..
  
  
  --
  Rob
  
 
 Humour me.

Please stop humouring our resident troll.

Re: [SPAM:9.6] Off Topic - SPF - What a Disaster

Christian Brel wrote:

 On Wed, 24 Feb 2010 11:39:43 +0100
 Rob Sterenborg r.sterenb...@netsourcing.nl wrote:
 
 On 2010-02-24, Kai Schaetzl wrote:
 
   Postfix:  I would have two different smtpd daemons - one for
 
  You don't have to run two postfixes for this.
 
 I think Per means: 2 smtpd processes, not 2 Postfixes..
 
 
 --
 Rob
 
 
 Humour me. Does this not mean a need to change the outbound to either
 a different IP or port? 

IP yes.  I assume your external and internal network are on different
IP-ranges. 

 I guess you could start hashing things around 
 with IPTables to redirect certain requests, but once you've done all
 of this, changed all the clients etc. etc, you are saying this would
 be *easier* than SPF?

See Mariusz Kruks suggestion - that's the way to do it.  Accept
everything from mynetworks, reject everything pretending to be coming
from your domain.  


/Per Jessen, Zürich

Re: [SPAM:9.6] Re: [SPAM:9.6] Off Topic - SPF - What a Disaster

On Wed, 24 Feb 2010 12:41:29 +0100
Per Jessen p...@computer.org wrote:

 Christian Brel wrote:
 
  On Wed, 24 Feb 2010 11:39:43 +0100
  Rob Sterenborg r.sterenb...@netsourcing.nl wrote:
  
  On 2010-02-24, Kai Schaetzl wrote:
  
Postfix:  I would have two different smtpd daemons - one for
  
   You don't have to run two postfixes for this.
  
  I think Per means: 2 smtpd processes, not 2 Postfixes..
  
  
  --
  Rob
  
  
  Humour me. Does this not mean a need to change the outbound to
  either a different IP or port? 
 
 IP yes.  I assume your external and internal network are on different
 IP-ranges. 

What about my home workers? I don't have a VPN, they hook in by DSL
from any number of different providers from outside using SASL/TLS.

It's like you say, you were thinking out loud and I can see where you
are coming from, but it's not a fix for every situation.

I'm also thinking about those forwarding services out there - does the
two SMTPd approach not break this in the same way SPF would break if
the forwarder was not permitted to send?

Re: [SPAM:9.6] Re: [SPAM:9.6] Off Topic - SPF - What a Disaster

On Wed, 24 Feb 2010 13:38:55 +0200
Henrik K h...@hege.li wrote:

 On Wed, Feb 24, 2010 at 11:30:25AM +, Christian Brel wrote:
  On Wed, 24 Feb 2010 11:39:43 +0100
  Rob Sterenborg r.sterenb...@netsourcing.nl wrote:
  
   On 2010-02-24, Kai Schaetzl wrote:
   
 Postfix:  I would have two different smtpd daemons - one for
   
You don't have to run two postfixes for this.
   
   I think Per means: 2 smtpd processes, not 2 Postfixes..
   
   
   --
   Rob
   
  
  Humour me.
 
 Please stop humouring our resident troll.
 

That would be you then as your post has no purpose other than to
inflame. Kinda reminds me of that old saying 'takes one to know one.'

Re: [SPAM:9.6] Re: [SPAM:9.6] Off Topic - SPF - What a Disaster

On Wednesday, 24 of February 2010, Christian Brel wrote:
  IP yes.  I assume your external and internal network are on different
  IP-ranges.
  What about my home workers? I don't have a VPN, they hook in by DSL
 from any number of different providers from outside using SASL/TLS.

They should be using submission service on port 587 and authenticate 
themselves, for example with smtp-auth. (of course you can still authenticate 
them and let them send on port 25 - it's perfectly possible from technical 
point of view; because you authenticate your clients, right?).

 I'm also thinking about those forwarding services out there - does the
 two SMTPd approach not break this in the same way SPF would break if
 the forwarder was not permitted to send?

In case of forwarding the envelope address is that of the original sender, not 
that of the receiver.
You have email from addre...@domain1.com to addre...@domain2.com. MX for 
domain2.com tries to forward the mail to addre...@domain3.com, so it sends 
mail from addre...@domain1.com to addre...@domain3.com. Domain3.com checks SPF 
records and sees that domain2.com is not permitted to send mails for 
domain1.com, so it refuses to accept such mail.
We were talking about (let's assume we're domain3.com) not letting people from 
outside world send mail from domain3.com.

-- 
  Kruk@ -\   | 
  }- epsilon.eu.org | 
http:// -/   | 
 |

Re: [SPAM:9.6] Re: [SPAM:9.6] Off Topic - SPF - What a Disaster

Christian Brel wrote:

  Humour me. Does this not mean a need to change the outbound to
  either a different IP or port?
 
 IP yes.  I assume your external and internal network are on different
 IP-ranges.
 
 What about my home workers? I don't have a VPN, they hook in by DSL
 from any number of different providers from outside using SASL/TLS.

Then presumably they submit email via port 587 after appropriate
authentication.  Then you just add that requirement - can't remember
what the exact postfix option is.  I have people working from
home-offices too, that's how they are set up. 

 It's like you say, you were thinking out loud and I can see where you
 are coming from, but it's not a fix for every situation.

I think it actually is.  Allow mynetworks, allow authenticated users,
reject everything else.

 I'm also thinking about those forwarding services out there - does the
 two SMTPd approach not break this in the same way SPF would break if
 the forwarder was not permitted to send?

I can't quite follow you - there's is no forwarding involved AFAICS?  


/Per Jessen, Zürich

Re: Off Topic - SPF - What a Disaster

2010-02-24 Thread Bowie Bailey

Matus UHLAR - fantomas wrote:
 On 23.02.10 16:17, Bowie Bailey wrote:
   
 SPF enforcement at the MTA is useless for the reasons you specified. 
 The only exception is if you have a strict SPF policy for your own
 domain, you can use it to reject spam pretending to be from your users.
 

 And what is this, if not enforcing SPF at MTA level?
   

This is selective enforcement of a domain (or list of domains) that are
known to have working SPF records.

 Also, this can be solved at MTA level without SPF enforcement. Afaik some
 servers are already rejecting mail from their users without proper
 authentification.
   

True, but then you need to keep track of which mail servers are allowed
to send mail for each domain.  Which, coincidentally, is exactly what
SPF does.

(This is assuming a more complex configuration than just rejecting
everything that does not originate locally.)

-- 
Bowie

Re: [SPAM:9.6] Re: [SPAM:9.6] Re: [SPAM:9.6] Off Topic - SPF - What a Disaster

On Wed, 24 Feb 2010 14:37:49 +0100
Per Jessen p...@computer.org wrote:

 Christian Brel wrote:
 
   Humour me. Does this not mean a need to change the outbound to
   either a different IP or port?
  
  IP yes.  I assume your external and internal network are on
  different IP-ranges.
  
  What about my home workers? I don't have a VPN, they hook in by DSL
  from any number of different providers from outside using SASL/TLS.
 
 Then presumably they submit email via port 587 after appropriate
 authentication. 
No, they submit on 25 using TLS+SASL. Would making
the changes to Firewall, MTA, plus potentially thosands of clients be
easier than SPF? Would all those angry users screaming because they
can't send mail at all be a good thing? I don't think so myself.

  It's like you say, you were thinking out loud and I can see where
  you are coming from, but it's not a fix for every situation.
 
 I think it actually is.  Allow mynetworks, allow authenticated users,
 reject everything else.
But that would reject *everything* that was not authenticated or in 'my
networks'. For a single IP/Port listening to the world this does not
work. It requires multiple SMTP instances with different IP's or Ports
which may not suit the needs of the admin and the users concerned.
 
Tell you what, wouldn't it be a great idea to save all the messing
around and use something universal and simple for the job? Something
lightweight and easy to deploy. I know! What about using SPF!

 
 /Per Jessen, Zürich
 
Of course, all this has very little to do with Spamassassin..

Re: [SPAM:9.6] Re: [SPAM:9.6] Re: [SPAM:9.6] Off Topic - SPF - What a Disaster

On Wednesday, 24 of February 2010, Christian Brel wrote:
 No, they submit on 25 using TLS+SASL. Would making
 the changes to Firewall, MTA, plus potentially thosands of clients be
 easier than SPF? Would all those angry users screaming because they
 can't send mail at all be a good thing? I don't think so myself.

Well, you _should_ use submission anyway.
(BTW, in my experience it's easier to filter one kind of traffic on 25, and 
another on 587 than filtering both on one port. YMMV)

   It's like you say, you were thinking out loud and I can see where
   you are coming from, but it's not a fix for every situation.
  I think it actually is.  Allow mynetworks, allow authenticated users,
  reject everything else.
 But that would reject *everything* that was not authenticated or in 'my
 networks'. For a single IP/Port listening to the world this does not
 work. It requires multiple SMTP instances with different IP's or Ports
 which may not suit the needs of the admin and the users concerned.

It doesn't.

permit mynetworks/sasl_authenticated/whatever,
reject my_domains, 
permit my_destination,
reject_everything_else.
Of course you may add other restrictions in this chain.


-- 
\.\.\.\.\.\.\.\.\.\.\.\.\.\ 
.\.k...@epsilon.eu.org.\.\. 
\.http://epsilon.eu.org/\.\ 
.\.\.\.\.\.\.\.\.\.\.\.\.\.

Re: [SPAM:9.6] [SPAM:9.6] Off Topic - SPF - What a Disaster

Christian Brel wrote on Wed, 24 Feb 2010 12:39:47 +:

 What about my home workers?

they use SMTP AUTH. It works, believe us. With a standard postfix.

Kai

-- 
Get your web at Conactive Internet Services: http://www.conactive.com

Re: Off Topic - SPF - What a Disaster

2010-02-24 Thread Matus UHLAR - fantomas

  On 23.02.10 16:17, Bowie Bailey wrote:
  SPF enforcement at the MTA is useless for the reasons you specified. 
  The only exception is if you have a strict SPF policy for your own
  domain, you can use it to reject spam pretending to be from your users.

 Matus UHLAR - fantomas wrote:
  And what is this, if not enforcing SPF at MTA level?

On 24.02.10 09:03, Bowie Bailey wrote:
 This is selective enforcement of a domain (or list of domains) that are
 known to have working SPF records.

so, it's enabling/disabling of SPF usage for some domains.

  Also, this can be solved at MTA level without SPF enforcement. Afaik some
  servers are already rejecting mail from their users without proper
  authentification.

 True, but then you need to keep track of which mail servers are allowed
 to send mail for each domain.  Which, coincidentally, is exactly what
 SPF does.

that's why I'd keep it on SPF, probably with listing of domains that
should/shoult not be checked. It's much easier to do it with SPF than
maintaining list of domains/servers.

And you can even tell which domains (or their users) have broken setup and
optionally notify them.

For some domains/senders (e.g. freemails), we could argument that it's the
freemail provider who wishes it this way and the sender is breaking the
domain policy...

 (This is assuming a more complex configuration than just rejecting
 everything that does not originate locally.)

otoh, it does much more for you.

-- 
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
One World. One Web. One Program. - Microsoft promotional advertisement
Ein Volk, ein Reich, ein Fuhrer! - Adolf Hitler

Re: [SPAM:9.6] Re: [SPAM:9.6] Re: [SPAM:9.6] Off Topic - SPF - What a Disaster

Christian Brel wrote:

 On Wed, 24 Feb 2010 14:37:49 +0100
 Per Jessen p...@computer.org wrote:
 
 Christian Brel wrote:
 
   Humour me. Does this not mean a need to change the outbound to
   either a different IP or port?
  
  IP yes.  I assume your external and internal network are on
  different IP-ranges.
  
  What about my home workers? I don't have a VPN, they hook in by DSL
  from any number of different providers from outside using SASL/TLS.
 
 Then presumably they submit email via port 587 after appropriate
 authentication.

 No, they submit on 25 using TLS+SASL. Would making
 the changes to Firewall, MTA, plus potentially thosands of clients be
 easier than SPF? Would all those angry users screaming because they
 can't send mail at all be a good thing? I don't think so myself.

Then keep them on port 25, it's no big deal as long as they are
authenticated. 

  It's like you say, you were thinking out loud and I can see where
  you are coming from, but it's not a fix for every situation.
 
 I think it actually is.  Allow mynetworks, allow authenticated users,
 reject everything else.

 But that would reject *everything* that was not authenticated or in
 'my networks'. 

No. See Mariusz' explanation. 

 Tell you what, wouldn't it be a great idea to save all the messing
 around and use something universal and simple for the job? Something
 lightweight and easy to deploy. I know! What about using SPF!

Christian, I suspect we don't have quite the same understanding of
what 'easy' means. 


/Per Jessen, Zürich

Re: [SPAM:9.6] [SPAM:9.6] [SPAM:9.6] Off Topic - SPF - What a Disaster

Christian Brel wrote on Wed, 24 Feb 2010 14:56:49 +:

 But that would reject *everything* that was not authenticated or in 'my
 networks'.

Indeed, that's the purpose. And it doesn't matter if you get the mail via 
25 or 587. 587 is just a convenience. Any other access to use your server 
for relaying should not be allowed at all. I really suggest you sit back 
and read the postfix documentation instead of questioning and questioning 
in the blue air. It's an absolute standard postfix configuration that you 
just seem to have not been made aware for years.

Kai

-- 
Get your web at Conactive Internet Services: http://www.conactive.com

Re: Off Topic - SPF - What a Disaster

On Wed, 24 Feb 2010 17:09:31 +0100
Per Jessen p...@computer.org wrote:


  Tell you what, wouldn't it be a great idea to save all the messing
  around and use something universal and simple for the job? Something
  lightweight and easy to deploy. I know! What about using SPF!
 
 Christian, I suspect we don't have quite the same understanding of
 what 'easy' means. 

I guess that is so.

Personally I find the multiple use of Postfixens trivial easy and have
it deployed that way to get over it's inability to whitelist body and
header checks {at all}. In general terms your fix may not suit
common MTA's like Exchange (I feel quite disgusted to have described
Exchange as an MTA and will now go and wash my typing fingers.)

I did find a bad place to use SPF - and that is
on a well known spam filter made by an American company. Enable it there
and watch the machine grind to a halt. 'it's a feature - not a bug'
LOL could'nt resist it... I'll get my coat..


 
 
 /Per Jessen, Zürich

Re: Off Topic - SPF - What a Disaster

2010-02-24 Thread Kelson


On 2/23/2010 6:33 PM, Marc Perkel wrote:

I agree. I've been in the spam filtering business for many years and
have yetto find any use for SPF at all. It's disturbing this useless
technology is getting the false positive support we are seeing.


And as people on this list have pointed out 5,000 times, including 
myself yesterday:


whitelist_from_spf  *...@example.com

This applies a whitelist rule to messages from example.com if and only 
if they also pass example.com's SPF policy.


So there's one use case right there, unless you're going to claim that 
functionality is useless.


--
Kelson Vibber
SpeedGate Communications www.speed.net

Re: [SPAM:9.6] [SPAM:9.6] [SPAM:9.6] Off Topic - SPF - What a Disaster