[IMGate] Re: Signed up for the spf stuff
Also, the big guys will be more likely to start enforcing spf values when they see many of us have properly setup SPF records. It takes about 5 minutes to implement and virtually no resources, I honestly see no excuse for not doing it or even debating doing it or not. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of A. Clausen Sent: Thursday, March 31, 2005 7:13 PM To: IMGate@mgw2.MEIway.com Subject: [IMGate] Re: Signed up for the spf stuff - Original Message - From: Christopher Checca [EMAIL PROTECTED] To: IMGate@mgw2.MEIway.com Sent: Wednesday, March 30, 2005 14:29 Subject: [IMGate] Re: Signed up for the spf stuff So, is SPF a whitelist feature? a blacklist feature? Since most of us have solved 98+% of our SPAM probles, SPF will at very best be tiny increment of help, and we are a long way from very best SPF implementation. My primary intest in making SPF records for all our mail domains is to ensure delivery with some of the big guys, which give some preferential waiting when an SPF record is found. -- A. Clausen
[IMGate] Re: Signed up for the spf stuff
Also, the big guys will be more likely to start enforcing spf values when they see many of us have properly setup SPF records. The big guys can force the issue, as only they have the power, but, as they have shown on PTR and helo hostnames, they refuse to wield their power. The big guys won't enforce new SPF anymore than they enforce ancient PTR and helo names. Len
[IMGate] Re: Signed up for the spf stuff
- Original Message - From: Christopher Checca [EMAIL PROTECTED] To: IMGate@mgw2.MEIway.com Sent: Wednesday, March 30, 2005 14:29 Subject: [IMGate] Re: Signed up for the spf stuff So, is SPF a whitelist feature? a blacklist feature? Since most of us have solved 98+% of our SPAM probles, SPF will at very best be tiny increment of help, and we are a long way from very best SPF implementation. My primary intest in making SPF records for all our mail domains is to ensure delivery with some of the big guys, which give some preferential waiting when an SPF record is found. -- A. Clausen
[IMGate] Re: Signed up for the spf stuff
Just curious on if any of you are signing up for this service? http://spf.pobox.com/ ---start of one man's opinion... quick! hit delete if you are easily offended :) No. Not until the big guys start using it. I don't mean when they add the records to their own domains, but instead, when they actually reject mail based on the absence of the spf records of others. Until then, it think it just makes some folks feel good to be in the spf club, but there really is no tangible benefit yet. ---end of opinion
[IMGate] Re: Signed up for the spf stuff
Also, there's nothing to sign up for. You can use SPF whether you register with spf.pobox.com or not. It is just DNS records.=20 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob McGregor Sent: Wednesday, March 30, 2005 4:30 PM To: IMGate List Subject: [IMGate] Signed up for the spf stuff Just curious on if any of you are signing up for this service? http://spf.pobox.com/
[IMGate] Re: Signed up for the spf stuff
Just curious on if any of you are signing up for this service? http://spf.pobox.com/ I follow the SPF list, here's msg of frustration from recently: I want an RfC for v=spf1 a.s.a.p. All these permanent modifications like adding zone-cut, removing zone-cut, use PRA instead of MAIL FROM, don't use PRA, MAYbe test HELO, ignore HELO, SHOULD test HELO, limit the processing time to at least 20 seconds, at most 20 seconds, at least 10 indirections, at most 10 indirectionss, exactly 10 mechanisms, 10 queries, etc. ...all this infuriates me. V=spf1 is supposed to be stable for more than a year now. I'm not interested in new features, as long as we don't have this one really stable RfC. Even if it is only experimental. In your case I felt that you insisted on going through a wall (anything with DNS is a wall from my POV), where I could see the SIQ-door, but couldn't explain the wall-part. Chris Haynes has now done it: It's not a theoretical problem with DNS, but only a practical problem with the deployment of new uses of DNS queries for new RRs like the future SPF RR. Back to square one: Adding new features to DNS is no option but a bad case of FUSSP - when all DNS libraries, servers, firewalls, and what else are updated. Yes, then we could do wonderful things. We could even forget SPF and implement CSV. But in practice that's not possible. SPF has reasons to abuse TXT at the moment, and this moment will last for decades plus the time wasted to get a RfC with the new SPF RR (without your modified query), It was a design decision to have a 1:1 correspondence between the old TXT RR solution and the new SPF RR. Maybe add an optional additional info section with the IP to these queries for v=spf6 or spf/6.0 later. But please stay away from v=spf1 as is before we have some kind of official RfC for v=spf1. It's already hell to get at least so far. The very last v=spf1 needs now are some new features. Let alone new features in its DNS layer. I appreciate your frustration. It sure seems like the entire technical community is floundering over what should be a simple standard. I don't mean the SPF standard, but a standard that all methods can live within. This would not include any controversial items like redirected queries, but just those few items needed for inter-operability of all methods. My worry is that we might get agreement within the SPF community, barely squeeze it through IETF, then face adamant opposition from SenderID, DomainKeys, and any other group that doesn't like the letters SPF in an authentication header. My suggestion is that we take one little step backwards and try for a standard that everyone can agree on (or at least make clear that their objections are frivolous). With a few items standardized, SPF and any other method can do whatever they want within the standard, and the much bigger community that is not involved in the competition between authentication methods (spam filter companies, ISPs, spam blocking services, etc.) - that much larger community can move forward, knowing exactly what an authentication header will look like. As for the opposition from the DNS community, I may be wrong because I haven't reviewed the earlier controversies, but I'll bet we can get them to help if we address their fundamental concerns, and enlist their help in coming up with a solution. We need them to think as proud fathers, not jealous guardians. Surely they would like to have their invention be a key player in the solution to a serious international problem. If not, there are alternatives. Here is what I see as the fundamental requirements for a standard authentication query: 1) The authentication query must be quick and independent of any particular method. The alternative is to have the sender declare the authentication method in the envelope, but let's put that option aside for the moment. 2) The response must be quick and allow rejection of most forgeries with no additional queries. I'm tempted to suggest how this might be done, but first let's see if anyone has objections to these requirements, or anything else we should add at this level. == Len from here: I get the general impression that SPF people are self-importantly debating angels on a pinhead. Meanhwile, only a tiny fraction of .com's 35 million domains have published SPF records, not even thinking about the many millions of domains under other TLDs. SPF sounded really simple and effective, but apparently not the case. there's spf1, spf2, spf classic, ad nauseam. Based on the number of legit servers, at this very late date in the spam war, that don't have PTR records, don't even have valid HELO hostnames, I'm very skeptical they will ever have SPF records. How to use SPF by your MS? @sender.domain has no SPF records? can't reject @sender.domain has SPF records, and msg is from SPF-defined IP, trust and accept? no, spammer domain have SPF
[IMGate] Re: Signed up for the spf stuff
So, is SPF a whitelist feature? a blacklist feature? Since most of us have solved 98+% of our SPAM probles, SPF will at very best be tiny increment of help, and we are a long way from very best SPF implementation. Len I see SPF records adding a low weight in the entire anti-spam system, but I see SPF as a whitelist feature. IMO SPF is dead as they high jacked a DNS record, spammers are adding SPF records faster than anyone, and not many admins can setup the mail server correctly as RFC's provide already. IMO the overall problem is the IT profession, IT went from professionals to anyone that could pass the M$ tests and could get cheap highspeed access for cheap. They aren't many true professionals in the IT field anymore ... again IMO ... it's really sad. ---off the soap box--- Christopher Checca Packard Transport, Inc. IT Department 24021 South Municipal Dr PO Box 380 Channahon, IL. 60410 815 467 9260 815 467 6939 Fax [EMAIL PROTECTED] www.packardtransport.com
[IMGate] Re: Signed up for the spf stuff
Personally I'd like to see Marking Mail Transfer Agents in Reverse DNS with TXT RRs ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-stumpf-dns-mtamark-03.txt move forward and get adopted. Sounds good to me, but so did SPF in the beginning. :) mtamark has, for me, the same problem as with SPF: When so many legit server have no PTR (we can't reject alone for no PTR) and bad helo (they can't set up their SMTP box), what chance is there for mtamark? However, the ground will move when/if aol/earthlink/yahoo/msn/hotmail ALL insist on PTR and valid helo. Then we can set our policies in sync with those de facto industry policies, with no need to hassle with recalcitrants. You can't send to aol/earthlink/yahoo/msn/hotmail with you noPTR/badHELO, and you WON'T send to my MX, either. From that point, then we can move try mtamark. The problem with mtamark is that so many legit orgs do not have authority over their reverse zone, making mtamark records dependent on the DNS admin for the reverse zone. Len
[IMGate] Re: Signed up for the spf stuff
Quoting Len Conrad [EMAIL PROTECTED]: Personally I'd like to see Marking Mail Transfer Agents in Reverse DNS with TXT RRs ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-stumpf-dns-mtamark-03.txt move forward and get adopted. Perhaps I misunderstood this RFC but it seems trivial for spammers to mark their ip's with a 1 or spam friendly providers to do the same. I agree it's effective against hijacked workstations, but then so is greylisting. Andrew P. Kaplan www.cshore.com This message was sent using IMP, the Internet Messaging Program.
