From owner-ietf-mxcomp@mail.imc.org Fri May 20 16:35:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12010 for ; Fri, 20 May 2005 16:35:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KK7dGi058137; Fri, 20 May 2005 13:07:39 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4KK7dYq058136; Fri, 20 May 2005 13:07:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4KK7cnG058086 for ; Fri, 20 May 2005 13:07:38 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id 1D4D5414EF; Fri, 20 May 2005 13:07:33 -0700 (PDT) Subject: draft-lyon-senderid-core-01.txt From: Douglas Otis To: MARID Cc: CLEAR WG Content-Type: text/plain Date: Fri, 20 May 2005 13:07:32 -0700 Message-Id: <1116619652.6507.179.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 1. Introduction ,---- | This document defines a pair of closely-related tests. One validates | a message's Purported Responsible Address (PRA) as defined in [PRA]. | The other validates a message's Reverse-Path (also known as MAIL-FROM | address) as defined in [SPF]. | | An e-mail sender complying with this specification SHOULD publish | information for both tests, and SHOULD arrange that any mail that is | sent will pass both tests. An e-mail receiver complying with this | specification SHOULD perform at least one of these tests. `---- This "SHOULD" advice makes it difficult for an email provider to ensure mailbox addresses are without conflict, without also licensing the PRA algorithm. 2. Problem Statement ,---- | In the long run, once the domain of the sender is authenticated, it | will be possible to use that domain as part of a mechanism to | determine the likelihood that a given message is spam, using, for | example, reputation and accreditation services. (These services are | not the subject of the present mechanism, but it should enable them.) `---- Because the server was authorized to support an "assumed accountable sender," this process has "authenticated" the sender? Would this be like me saying "Because I authorized the postal service, and express carrier, therefore any letter from them bearing my name is "authentically" from me." Reconsider the problem of not knowing which identity was implied by the sender initially. While this mechanism provides for a case where a message arrives through an unauthorized server, which may allow the message to be rejected, this by no means provides assurances sufficient for accruing reputations against the "assumed accountable sender." This would be wholly unfair. 3.1 Version and Scope ,---- | Under Sender ID, receiving domains may perform a check of either the | PRA identity or the MAIL-FROM identity. Sending domains therefore | require a method for declaring whether their published list of | authorized outbound e-mail servers can be used for the PRA check, | the MAIL-FROM check or both. `---- This does not prioritize these two checks. 3.4 Compatibility ,---- | Domain administrators complying with this specification are required | to publish information in DNS regarding their authorized outbound | e-mail servers. [SPF] describes a format for this information | identified by the version prefix "v=spf1". Many domains have | published information in DNS using this format. In order to | provide compatibility for these domains, Sender ID implementations | SHOULD interpret the version prefix "v=spf1" as equivalent to | "spf2.0/mfrom,pra", provided no record starting with "spf2.0" exists. | | Administrators who have already published "v=spf1" records SHOULD | review these records to determine whether they are also valid for use | with PRA checks. If the information in a "v=spf1" record is not | correct for a PRA check, administrators SHOULD publish either an | "spf2.0/pra" record with correct information, or an "spf2.0/pra ?all" | record indicating that the result of a PRA check is explicitly | inconclusive. `---- Those that do not wish to be assessed by a system using a dubious "authorization" as a basis for compiling reputations, will have difficulty expressing this desire as a result of these semantics. To "opt-out" of Sender-ID, a weak level of authorization must still be offered. There have been presentations where weak authorizations would eventually be refused, and coupled with warnings these types of records could potentially lead to damaging one's reputation. I would describe this as the "Sender-ID trap." 6.1 DNS Attacks ,---- | An MTA could largely defeat such an attack by using a properly | paranoid DNS resolver. `---- While noting the format and related processing of the DNS record is defined in draft-schlitt-spf-classic-00, it seems this statement could elaborate on specific attacks. Warnings regarding the processing of lookups in parallel, asserting a truncated timeout, or preventing replicate lookups, rather than assuming any attack related specifically to SPF/Sender-ID is resolved by way of paranoia. : ) 7.1 Simple E-mailers ,---- | In the majority of cases, the domain's published information will be | the same for both the PRA and MAIL FROM variants of this test. In | this case, domains SHOULD publish their information using an SPF | record with the prefix "v=spf1". Doing so will render their | published information usable by the older SPF protocol, too. (See | [SPF] for information on the SPF protocol.) `---- A SHOULD publish "v=spf1" interpreted as applying to either PRA or MAILFROM ensures lack of clarity. To achieve a modicum of spoofing resistance, depreciate "v=spf1" in the SPF draft, which is integral to this draft. 7.2 E-Mail Forwarders ,---- | In order to pass the PRA variant of the test, a program that forwards | received mail to other addresses MUST add an appropriate header that | contains an e-mail address that it is authorized to use. Such | programs SHOULD use the Resent-From header for this purpose. | | In order to pass the MAIL FROM variant of the test, a program that | forwards received mail to other addresses MUST alter the MAIL FROM | address to an address under its control. Should that address | eventually receive a DSN relating to the original message, that DSN | SHOULD be forwarded to the original MAIL FROM address. However, if | this altered address receives any messages other than DSNs related to | the original message, these messages MUST NOT be forwarded to the | original MAIL FROM address; they SHOULD be refused during an SMTP | transaction. `---- Forwarding DSN? This seems challenging and problematic. This also drops the typical "on vacation" response. It also weakens BATV efforts. 7.5 MUA Implementers ,---- | When displaying a received message, an MUA SHOULD display the | purported responsible address as defined by this document whenever | that address differs from the RFC 2822 From address. This display | SHOULD be in addition to the RFC 2822 From address. `---- Again another SHOULD use a licensed algorithm? Although this may be intended to stop phishing attacks made against financial institutions, the predominate MUA does not display anything other than the pretty name of the From. In addition, Sender-ID places the From at the lowest priority of accepted headers. As another consideration, financial institutions place great value on assured delivery, that is incompatible with the strict authorization needed to protect the user from seeing phishing attempts. There are less wrenching and safer alternatives. If financial institutions were to use S/MIME and browser compatible certificates, this could already be handled by more than 400 million email clients such as Outlook, Outlook Express, Lotus Notes, Novell Groupwise, Netscape, Mac Mail, Mozilla, Thunderbird, Eudora, Becky!, Bat!, Mulberry, Blackberry, and more. If not understood by the MUA, or the recipient is aware of signature related problems with their provider, the signature attachment could be ignored. At least wary recipients could check certificates to be assured of the From address without using a proprietary MUA. In addition, there are other lower cost signature schemes, such as DomainKeys, that can be implemented on the MSA and MDA, independent of the MUA, and afford real consumer protections with much stronger assurances, without expecting all users will adopt a proprietary MUA. Calling Sender-ID "Sender Authentication" should stop. This is overstating to a great degree the assurances afforded from a confirmation of server authorization by an apparent sender. Remember, these records are public, and it is typical for email providers to be shared by many different domain owners. It is hard enough getting providers to authenticate their clients, without expecting them to enforce new constraints that are sure to cause endless complaints. While it remains the email provider most able to ensure abuse is curtailed, Sender-ID ignores their accountability. I find it difficult trust this approach that offers no means to verify who was actually accountable. At least with a signature, there is little doubt. -Doug From owner-ietf-mxcomp@mail.imc.org Wed May 25 20:20:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11092 for ; Wed, 25 May 2005 20:20:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PNpZ5c031685; Wed, 25 May 2005 16:51:35 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4PNpZDh031684; Wed, 25 May 2005 16:51:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4PNpYB4031621 for ; Wed, 25 May 2005 16:51:34 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id 7DEA9414F4 for ; Wed, 25 May 2005 16:51:14 -0700 (PDT) Subject: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/" From: Douglas Otis To: MARID Content-Type: text/plain; charset=UTF-8 Date: Wed, 25 May 2005 16:51:13 -0700 Message-Id: <1117065074.14235.145.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit The following is a greeting when subscribing to spf-discuss: ------------------------------- > Hi! You have asked to subscribe to the mailing list > spf-discuss@v2.listbox.com. If this is what you want, > just reply to this message or click on the link below, > and you will be subscribed to the list. > > http://v2.listbox.com/subscribe/?confirm=xxxxxxxxxxxxxxx > > This list is for open discussion of the proposed SPF standard. > > Subscription to this list, and posting to it, is a privilege, not a > right. > The list operates according to the best practices described at > RFC1855. > You should also review > http://www.ietf.org/proceedings/02mar/slides/plenary-3/ > > Revocation of privileges operates according to an abbreviated form of > BCP83. > In short: kooks, crazy people, and rude people should expect to be > unsubscribed. > ,--- > | The SPF mailing list is intended for constructive discussion and > | promotion of SPF. If you believe that the SPF concept is > | fundamentally flawed, please subscribe instead to the ietf-mxcomp > | mailing list at http://www.imc.org/ietf-mxcomp/ > '--- > > The SPF standard originated as a hybrid of Gordon Fecyk's DMP > proposal and Hadmut Danisch's RMX proposal. It now provides > a superset of their functionality. More information at > http://spf.pobox.com/ > > November 2004: The Messaging Anti-Abuse Working Group > sponsors a white paper titled Sender Authentication: What To Do. > http://spf.pobox.com/whitepaper.pdf > Please read it! > > October 2004: Microsoft encourages the publication of SPF > records. Microsoft will use a modified form of SPF, known as > "Sender ID", to check message headers in MUAs. Most other > MTA implementations continue to use SPF in its original form, > to check the return-path at SMTP time. > > Official announcements regarding SPF will be made on this list > and also on the announcements-only list, spf-announce@v2.listbox.com, > so you don't need to subscribe to both lists. > > List archives are available at > http://archives.listbox.com/spf-discuss/current/ > > Read and contribute documentation at the Wiki! > http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/ > > FOR DOMAIN OWNERS > > SPF is now ready for widespread adoption. If you control a > domain, you should publish SPF records for it now. You can > get started at http://spf.pobox.com/wizard.html. It takes most > people about 10 minutes to learn about SPF and 5 minutes to > write the records. > > FOR MAIL ADMINS > > You can download plugins for Postfix, Exim, Qmail, Sendmail, > Exchange, and other MTAs from http://spf.pobox.com/downloads.html. > > FOR DEVELOPERS > > One of SPF's design goals is to be simple, quick, and easy for domain > owners to publish records. We have met this goal at the cost of > some complexity on the client end. Most developers accept this > tradeoff. ----------------------------------- It would appear subscription to spf-discuss acknowledges acceptance of the SPF concept. However, problems related to SPF have become even more pronounced since dissolution of the MARID WG. Sender-ID has usurped the initial SPF record for PRA evaluation, and is advising use of methods in conflict with bounce-address validation efforts. The Sender Authentication Whitepaper, passed on to MAAWG from the FTC conference, has not undergone requested changes. There are several assertions that remain misleading and in error. SPF _is_ fundamentally flawed as it removes accountability from the email providers, at the expense of the domain owners and consumers. Contrary to the promotions, SPF will not stop spam. SPF will not prevent your domain from being forged, without great diligence by now anonymous email providers, as well as, universal compliance at each public MTA, and a slew of modification made to every email client. I can not accept the premise there are no serious concerns related to publishing SPF records. No scheme without a reputation assessment will prevent email abuse. Abusers are among the first to adopt changes offering greater access. Reputation puts the teeth in any email protection scheme. Beware, SPF may bite! You may get bit by recipients that consider SPF authorization is equivalent to identifying the source of a message. This assumption is unsafe and wholly unfair. This assumption is unsafe as forgery can still continue. This assumption is unfair as a basis for accruing the reputation of a domain owner, as they often have no administrative oversight with which to assure their protection. Instead of SPF records preventing harm when a domain is forged, SPF authorization may actually cause an otherwise impeccable domain obtain a bad reputation, when forgery nevertheless continues. Abusers may actually utilize your SPF records to usurp previously good reputations. What is worse, redemption of your reputation may not be practical. Abusers may take advantage of your desire to ensure your emails are delivered. Abusers may also take advantage of your email provider's desire to not license Microsoft's Sender-ID algorithm, which sets terms incompatible with open-source software. The selected domain offering server authorization is assumed to have originated the message. Microsoft calls this unfair assumption, “Sender Authentication.” Calling Sender-ID “Sender Authentication” would be like me making a declaration that the postal service is authorized to deliver my letters, where recipients are then claiming any letter received from the postal service bearing my name anywhere is authentically or genuinely from me. Of course that would be a false assumption, and Sender-ID is no different. How will abusers take advantage of these normal desires and false assumptions? While strictly limiting authorization to just the email provider's servers reduces some risk of your domain being forged, this may cause your messages to become lost as a result. This loss may occur when recipients use providers that select accountable domains based upon the “classic” bounce-address algorithm. The recipient may forward messages, which then makes your message appear to be from an unauthorized server. Your message may also become lost when sent through some list-servers, or through servers running older versions of email protocol. Why quibble over who is responsible for implementing a plethora of fixes, where any change to email often takes decades? The remedy for the loss of your messages is to leave your SPF server authorization list open-ended. When from an unknown server, the open-ended list then declares a lowered level of authorization. This lowered level of authorization is intended to alert recipients to increase the scrutiny given such messages. However, this lowered level of authorization will not ensure your reputation remains protected from forgery. For example, abusers take advantage of Microsoft's automatic image fetching to compile valuable lists of active email accounts, just by using encoded image links. These abusers don't really care which folder or level of authorization they obtain. They don't care that recipients fail to respond to their email either. These abusers would be thrilled to see recipients unsubscribe. Your concern is whether the recipient also clicks the “spam” button, when these messages have forged your domain. With SPF records being very public, your domain's reputation will be exposed to any abuse possible. Publishing open-ended SPF records may even act as an invitation, should a SPF reference become mandated by some providers. Furthermore, a provider that does not ensure Sender-ID headers are not in conflict with any of their other customers, may risk your domain's reputation, especially when this provider's limitation becomes known. When viewed by Sender-ID, such providers can not ensure your domain will not be forged. Of course, Microsoft may see this problem as being to their advantage. Once this becomes enough of a problem for domain owners, providers may find it necessary to license Microsoft's algorithm after all. With phishing techniques becoming seemingly epidemic, Microsoft is quick to offer Sender-ID as a remedy. With respect to phishing, Sender-ID considers the From header as the lowest priority for basing acceptance, even though this is the header typically seen by the recipient. Microsoft has made this problem worse by displaying the user friendly name, known as the “pretty” name, rather than the actual mailbox address. Phishing ploys often use disposable domain names for obfuscated links, which could also provide SPF authorizations. SPF records can also be constructed to covertly and fully authorize all servers within the entire Internet. SPF can covertly enable Zombies anywhere in the world. Sender-ID, even as a lame phishing deterrent, presumes wide adoption of proprietary algorithms by mail clients and providers. Assurances offered by Sender-ID aware applications are dangerous, due to the acceptance of hidden headers, and expectations of compliance to these proprietary algorithms. This may actually place consumers trusting such assurances in greater peril. Sender-ID itself may weaken the integrity of the DNS, where Microsoft only offers the advice that providers use "properly paranoid DNS resolvers.” Sender-ID requires that domain owners trust their email providers, although many providers do not authenticate their own customers. Heedless publishing of SPF will expose domain owners to substantial risk. In addition, Sender-ID does not identify these providers either, so there is little to directly motivate email provider diligence. Signatures are a safer alternative to this nonsensical approach that depends upon a magic wand that mysteriously transforms “server authorization” into “sender authentication.” There is already a digital signature technology, S/MIME, that can be handled by more than 400 million email clients such as Outlook, Outlook Express, Lotus Notes, Novell Groupwise, Netscape, Mac Mail, Mozilla, Thunderbird, Eudora, Becky!, Bat!, Mulberry, Blackberry, and more. Surely, financial institutions being phished can afford the digital certificates needed to verify their From address. Very soon major providers will offer DomainKeys signatures on outbound messages, and will be checking these signatures when messages enter their email gateway. The use of email signatures is on the near horizon. DomainKeys can be deployed within email gateways, and easily implemented. Compared to S/MIME with browser Certificate Authorities, DomainKeys lowers cost barriers, and does not depend upon the end-user email applications. When deployed for solicitations unrelated to commerce, cost is often a greater concern as well. Signatures can indicate where the message originated, regardless of the use of subsequent relays, or message forwarding, and offer a truly safe means to defeat phishing attempts. Unlike signature methods, Sender-ID limits the domain owner's choice of providers, and will likely create endless consumer complaints. Signatures indicate where the message originated without changing email's architectural paradigms. Signature verification only requires the recipient make the required checks, and is not required that these checks be performed at every intervening server that relays the message. Even spoofed bounce messages can be curtailed by signing the bounce-address using Bounce Address Tag Validation. Domain owners can sign their own email, and safely use providers that may exercise dubious diligence, without jeopardizing their domain's reputation or exposing their recipients to phishing threats. There is little benefit derived from jumping upon the Sender-ID bandwagon, but there is much more to loose when publishing SPF records. Consider DomainKeys instead. -Doug From owner-ietf-mxcomp@mail.imc.org Wed May 25 21:24:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19995 for ; Wed, 25 May 2005 21:24:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q133bQ051130; Wed, 25 May 2005 18:03:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4Q133bm051129; Wed, 25 May 2005 18:03:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from io.link-m.de (daemon@io.link-m.de [195.30.85.225]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q13266051110 for ; Wed, 25 May 2005 18:03:02 -0700 (PDT) (envelope-from bulk@mehnle.net) Received: from gray.home.mehnle.net (p549A78C5.dip.t-dialin.net [::ffff:84.154.120.197]) (AUTH: PLAIN julian@mehnle.net, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by io.link-m.de with esmtp; Thu, 26 May 2005 03:02:59 +0200 id 00000152.42952043.00003AE5 From: Julian Mehnle Reply-To: julian@mehnle.net To: MARID Subject: Re: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/" Date: Thu, 26 May 2005 03:02:48 +0200 User-Agent: KMail/1.7.2 References: <1117065074.14235.145.camel@SJC-Office-DHCP-156.mail-abuse.org> In-Reply-To: <1117065074.14235.145.camel@SJC-Office-DHCP-156.mail-abuse.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1209236.arSYxG45PJ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200505260302.49515.bulk@mehnle.net> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --nextPart1209236.arSYxG45PJ Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Douglas Otis wrote: > The following is a greeting when subscribing to spf-discuss: > ------------------------------- > > [...] > > ,--- > > | The SPF mailing list is intended for constructive discussion and > > | promotion of SPF. If you believe that the SPF concept is > > | fundamentally flawed, please subscribe instead to the ietf-mxcomp > > | mailing list at http://www.imc.org/ietf-mxcomp/ > > '--- > > [...] > ----------------------------------- > > It would appear subscription to spf-discuss acknowledges acceptance of > the SPF concept. True. Constructive criticism is welcome, but the SPF community is for the= =20 largest part convinced that the concept in itself is not fundamentally=20 flawed, so any criticism that implies the contrary is not considered=20 constructive. We have had so many flamewars on spf-discuss in the past that it seriously= =20 disturbed any constructive work. That made us, who were concinved of SPF=20 and wanted to get some real work done, draw a line. There are many forums where destructive criticism about SPF is welcome. If= =20 you need one, you know where to find one. > However, problems related to SPF have become even more=20 > pronounced since dissolution of the MARID WG. Sender-ID has usurped the > initial SPF record for PRA evaluation, and is advising use of methods in > conflict with bounce-address validation efforts. Obviously, this is not an inherent problem of SPF, but a problem of the=20 Sender-ID drafts. We are currently working with the IETF to resolve this=20 issue. > The Sender Authentication Whitepaper, passed on to MAAWG from the FTC > conference, has not undergone requested changes. There are several > assertions that remain misleading and in error. > > SPF _is_ fundamentally flawed as it removes accountability from the > email providers, at the expense of the domain owners and consumers. This is a highly subjective assessment, nothing more. > Contrary to the promotions, SPF will not stop spam. Who is promoting SPF as an anti-spam solution? I'd really like to know. > SPF will not prevent your domain from being forged, without great > diligence by now anonymous email providers, as well as, universal > compliance at each public MTA, Absolute security requires absolute deployment. Not even PGP is going to=20 absolutely guarantee the authenticity of your messages if 95% of the world= =20 can't check your signatures due to lacking PGP support. > and a slew of modification made to every email client. Nonsense. Show us why. > I can not accept the premise there are no serious concerns related to > publishing SPF records. No scheme without a reputation assessment will > prevent email abuse. SPF is about establishing authenticity. Reputation assessment is separate. > Abusers are among the first to adopt changes offering greater access. He who favors messages simply because they yield SPF "Pass" results has not= =20 understood SPF. > Abusers may actually utilize your SPF records to usurp previously good > reputations. Only if you let them. > What is worse, redemption of your reputation may not be practical. So, are you saying that the concepts of accountability and reputation are=20 fundamentally flawed? Besides, did I mention reputation assignment and assessment is separate=20 from SPF? The rest I don't bother commenting on. I advise people to make up their=20 own minds instead of buying into FUD. > Beware, SPF may bite! Woof, indeed! --nextPart1209236.arSYxG45PJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBClSA5wL7PKlBZWjsRAm5fAKCBjvUA5aitE4Lai6EPX5tyYm2TQQCg5uQn yKkbXnKdGf57EBbJwjB73JQ= =/rcF -----END PGP SIGNATURE----- --nextPart1209236.arSYxG45PJ-- From owner-ietf-mxcomp@mail.imc.org Wed May 25 21:42:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20915 for ; Wed, 25 May 2005 21:42:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q1OW2h055344; Wed, 25 May 2005 18:24:32 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4Q1OWkY055343; Wed, 25 May 2005 18:24:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from imo-m21.mx.aol.com (imo-m21.mx.aol.com [64.12.137.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q1OVbZ055330 for ; Wed, 25 May 2005 18:24:32 -0700 (PDT) (envelope-from CDHutzler@aol.com) Received: from CDHutzler@aol.com by imo-m21.mx.aol.com (mail_out_v38_r1.7.) id 7.201.2548863 (15899) for ; Wed, 25 May 2005 21:24:20 -0400 (EDT) Received: from [192.168.1.103] (pcp02139026pcs.reston01.va.comcast.net [68.48.28.95]) by air-id09.mx.aol.com (vx) with ESMTP id MAILINID92-3e1b429525432a5; Wed, 25 May 2005 21:24:20 -0400 Message-ID: <42952544.1050702@aol.com> Date: Wed, 25 May 2005 21:24:20 -0400 From: Carl Hutzler User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: MARID Subject: Re: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/" References: <1117065074.14235.145.camel@SJC-Office-DHCP-156.mail-abuse.org> <200505260302.49515.bulk@mehnle.net> In-Reply-To: <200505260302.49515.bulk@mehnle.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 68.48.28.95 X-Mailer: Unknown (No Version) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Is this use of SPF flawed? helo domain.com mail from: someone@domain.com Look up domain.com SPF record If the [connecting IP] = [SPF record] then "trust it more/whitelist" else do nothing end if Lets not destroy SPF records. They contain valuable reverse MX records which cover well over 95% of the email traffic on the internet today. If people choose to block based on negative SPF checks, it is their mail system and hence their rules. Perhaps SPF should be updated to have the above logic. Maybe this would be an interesting topic to discuss with "them". Back to my day job :-) -Carl -- Carl Hutzler Director, Host Mail Development America Online cdhutzler@aol.com 703.265.5521 work 703.915.6862 cell From owner-ietf-mxcomp@mail.imc.org Wed May 25 22:08:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22430 for ; Wed, 25 May 2005 22:08:04 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q1lToI058015; Wed, 25 May 2005 18:47:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4Q1lTXC058014; Wed, 25 May 2005 18:47:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.schlitt.net (schlitt.net [67.52.51.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q1l4s1057758 for ; Wed, 25 May 2005 18:47:28 -0700 (PDT) (envelope-from wayne@schlitt.net) Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1Db7Sb-0004oz-AW for ietf-mxcomp@imc.org; Wed, 25 May 2005 20:47:03 -0500 To: "IETF MARID WG" References: <1117065074.14235.145.camel@SJC-Office-DHCP-156.mail-abuse.org> <200505260302.49515.bulk@mehnle.net> From: wayne Mail-Copies-To: nobody Reply-To: "IETF MARID WG" Content-Type: text/plain; charset=US-ASCII Date: Wed, 25 May 2005 20:46:56 -0500 In-Reply-To: <200505260302.49515.bulk@mehnle.net> (Julian Mehnle's message of "Thu, 26 May 2005 03:02:48 +0200") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on backbone.schlitt.net X-Spam-Status: No, score=-5.2 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <200505260302.49515.bulk@mehnle.net> Julian Mehnle writes: > Douglas Otis wrote: >> Contrary to the promotions, SPF will not stop spam. > > Who is promoting SPF as an anti-spam solution? I'd really like to know. There are quite a few references on the spf.pobox.com website about stopping spam. Meng once said, and I agree with it, that SPF is an anti-spam product like flour is a food. -wayne From owner-ietf-mxcomp@mail.imc.org Wed May 25 22:35:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24472 for ; Wed, 25 May 2005 22:35:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q2FGi9071678; Wed, 25 May 2005 19:15:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4Q2FG07071677; Wed, 25 May 2005 19:15:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4Q2FFlC071669 for ; Wed, 25 May 2005 19:15:15 -0700 (PDT) (envelope-from prvs=johnl/09290505df@iecc.com) Received: (qmail 16321 invoked by uid 100); 26 May 2005 02:15:14 -0000 Date: 26 May 2005 02:15:14 -0000 Message-ID: <20050526021514.16320.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http: //www.imc.org/ietf-mxcomp/" In-Reply-To: <200505260302.49515.bulk@mehnle.net> Organization: I.E.C.C., Trumansburg NY USA Cc: julian@mehnle.net Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >> Contrary to the promotions, SPF will not stop spam. > >Who is promoting SPF as an anti-spam solution? I'd really like to know. Let's take a look at http://spf.pobox.org. Hey, look what it says: SPF is ushering in a new set of anti-spam systems, where email is spam unless proven otherwise. If history is any guide, some SPF fan will write back in a huff and say "That doesn't say SPF is an anti-spam solution! It just says that SPF is holding a flashlight and will lead the actual anti-spam solutions to their seats!" This kind of disingenuous doubletalk has characterized SPF advocacy since its beginning, and is one of the many reasons that the mainstream e-mail tech community holds SPF in disdain. That along with its egregious design mistakes and its irreparably enormous error rate, of course. SPF can help whitelist mail from fixed source senders you already know. That's what AOL uses it for, and it's an adequate if overly complex means to that end. If the SPF crowd promoted it for that purpose, I don't think anyone would have a problem with it. But they don't and the smoke long ago became unbreathable. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor "A book is a sneeze." - E.B. White, on the writing of Charlotte's Web From owner-ietf-mxcomp@mail.imc.org Wed May 25 23:46:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01547 for ; Wed, 25 May 2005 23:46:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q3H347081807; Wed, 25 May 2005 20:17:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4Q3H3nS081806; Wed, 25 May 2005 20:17:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4Q3H2Hm081800 for ; Wed, 25 May 2005 20:17:02 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j4Q3H0VB022235; Wed, 25 May 2005 20:17:00 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j4Q3GxPF022232; Wed, 25 May 2005 20:17:00 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Wed, 25 May 2005 20:16:59 -0700 (PDT) From: "william(at)elan.net" To: Carl Hutzler cc: MARID Subject: Re: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/" In-Reply-To: <42952544.1050702@aol.com> Message-ID: References: <1117065074.14235.145.camel@SJC-Office-DHCP-156.mail-abuse.org> <200505260302.49515.bulk@mehnle.net> <42952544.1050702@aol.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 25 May 2005, Carl Hutzler wrote: > Is this use of SPF flawed? > > helo domain.com > mail from: someone@domain.com > > Look up domain.com SPF record > > If the [connecting IP] = [SPF record] then "trust it more/whitelist" > else > do nothing > end if Ok, what do you do with this?: EHLO coolaid.example.net MAIL FROM: bigbug@example.com Yes, I'm interested in hearing from AOL perspective. --- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Thu May 26 07:29:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20853 for ; Thu, 26 May 2005 07:29:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QB7md9058835; Thu, 26 May 2005 04:07:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QB7mBa058834; Thu, 26 May 2005 04:07:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QB7kIM058824 for ; Thu, 26 May 2005 04:07:47 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DbGAk-0003UB-Gc for ietf-mxcomp@imc.org; Thu, 26 May 2005 13:05:06 +0200 Received: from c-134-89-89.hh.dial.de.ignite.net ([62.134.89.89]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 May 2005 13:05:06 +0200 Received: from nobody by c-134-89-89.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 May 2005 13:05:06 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: SPF PASS (was: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/") Date: Thu, 26 May 2005 13:06:09 +0200 Organization: Lines: 29 Message-ID: <4295ADA1.2343@xyzzy.claranet.de> References: <1117065074.14235.145.camel@SJC-Office-DHCP-156.mail-abuse.org> <200505260302.49515.bulk@mehnle.net> <42952544.1050702@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-89-89.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Carl Hutzler wrote: > Is this use of SPF flawed? [...] > If the [connecting IP] = [SPF record] then "trust it > more/whitelist" It's perfectly possible for a spammer to get a PASS. You wouldn't whitelist a spammer. But it's impossible for a spammer to pretend to be me, he'd get a FAIL (in my case). Unless I'm this spammer of course. > valuable reverse MX records which cover well over 95% of > the email traffic on the internet today. Is that a guess ? 95% is a rather high number. > Perhaps SPF should be updated to have the above logic. You can use it this way. But whitelisting a PASS only because it's a PASS is no long term strategy: "v=spf1 +exists:{ir}.comcast.blackholes.us -all" > Back to my day job :-) Be careful with mail from these comcast IPs, bye, Frank From owner-ietf-mxcomp@mail.imc.org Thu May 26 07:30:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20892 for ; Thu, 26 May 2005 07:30:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QBCHtn059385; Thu, 26 May 2005 04:12:17 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QBCH4f059384; Thu, 26 May 2005 04:12:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from imo-d05.mx.aol.com (imo-d05.mx.aol.com [205.188.157.37]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QBCGh8059378 for ; Thu, 26 May 2005 04:12:16 -0700 (PDT) (envelope-from CDHutzler@aol.com) Received: from CDHutzler@aol.com by imo-d05.mx.aol.com (mail_out_v38_r1.7.) id z.1ec.3bc8eb8e (16100); Thu, 26 May 2005 07:12:03 -0400 (EDT) Received: from [192.168.1.103] (pcp02139026pcs.reston01.va.comcast.net [68.48.28.95]) by air-id11.mx.aol.com (v106.2) with ESMTP id MAILINID114-3ee44295aefa2da; Thu, 26 May 2005 07:12:03 -0400 Message-ID: <4295AEFA.20401@aol.com> Date: Thu, 26 May 2005 07:11:54 -0400 From: Carl Hutzler User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: william@elan.net CC: MARID Subject: Re: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/" References: <1117065074.14235.145.camel@SJC-Office-DHCP-156.mail-abuse.org> <200505260302.49515.bulk@mehnle.net> <42952544.1050702@aol.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 68.48.28.95 X-Mailer: Unknown (No Version) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit william@elan.net wrote: > > > On Wed, 25 May 2005, Carl Hutzler wrote: > >> Is this use of SPF flawed? >> >> helo domain.com >> mail from: someone@domain.com >> >> Look up domain.com SPF record >> >> If the [connecting IP] = [SPF record] then "trust it more/whitelist" >> else >> do nothing >> end if > > > Ok, what do you do with this?: > > EHLO coolaid.example.net > MAIL FROM: bigbug@example.com > > Yes, I'm interested in hearing from AOL perspective. > > --- William Leibzon > Elan Networks > william@elan.net > Nothing different. The EHLO is not involved (unless we decide to do CSV :-) I should have left it out of my example. -- Carl Hutzler Director, Host Mail Development America Online cdhutzler@aol.com 703.265.5521 work 703.915.6862 cell From owner-ietf-mxcomp@mail.imc.org Thu May 26 07:45:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21676 for ; Thu, 26 May 2005 07:45:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QBKmST062749; Thu, 26 May 2005 04:20:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QBKmcY062748; Thu, 26 May 2005 04:20:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from imo-m28.mx.aol.com (imo-m28.mx.aol.com [64.12.137.9]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QBKlIP062669 for ; Thu, 26 May 2005 04:20:47 -0700 (PDT) (envelope-from CDHutzler@aol.com) Received: from CDHutzler@aol.com by imo-m28.mx.aol.com (mail_out_v38_r1.7.) id 5.1f6.a8bbc10 (15898); Thu, 26 May 2005 07:20:37 -0400 (EDT) Received: from [192.168.1.103] (pcp02139026pcs.reston01.va.comcast.net [68.48.28.95]) by air-id09.mx.aol.com (v106.2) with ESMTP id MAILINID91-3e1a4295b10524b; Thu, 26 May 2005 07:20:37 -0400 Message-ID: <4295B105.1030103@aol.com> Date: Thu, 26 May 2005 07:20:37 -0400 From: Carl Hutzler User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: nobody@xyzzy.claranet.de CC: ietf-mxcomp@imc.org Subject: Re: SPF PASS (was: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/") References: <1117065074.14235.145.camel@SJC-Office-DHCP-156.mail-abuse.org> <200505260302.49515.bulk@mehnle.net> <42952544.1050702@aol.com> <4295ADA1.2343@xyzzy.claranet.de> In-Reply-To: <4295ADA1.2343@xyzzy.claranet.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 68.48.28.95 X-Mailer: Unknown (No Version) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit nobody@xyzzy.claranet.de wrote: >Carl Hutzler wrote: > > > >>Is this use of SPF flawed? >> >> >[...] > > >>If the [connecting IP] = [SPF record] then "trust it >>more/whitelist" >> >> > >It's perfectly possible for a spammer to get a PASS. You >wouldn't whitelist a spammer. But it's impossible for a >spammer to pretend to be me, he'd get a FAIL (in my case). > >Unless I'm this spammer of course. > > > Actually, we DO WHITELIST SPAMMERS. I mean it happens. We don't want it to happen a lot, but it does. See we also monitor everyone on the WL very closely via volume, complaint, and bounce rates. So while a spammer could get onto the whitelist, they won't be for long. And a new spammer will have very low limits placed on how much they can send via a simple SPF=whitelist type method. Now if they prove once on the SPF=whitelist that they are a good sender, we would bump up their rate limits....or if they contact us to get "accredited" via our postmaster.aol.com webpage where you can simply ask to be on the whitelist, we might let them in with higher limits on day 1. We do this of course for well known organizations. >>valuable reverse MX records which cover well over 95% of >>the email traffic on the internet today. >> >> > >Is that a guess ? 95% is a rather high number. > > > OK, 85%. Is that better? Still beats the 80/20 rule easily. How much mail is not sent directly from the sending ISP to the destination ISP. For AOL it is a small number. >>Perhaps SPF should be updated to have the above logic. >> >> > >You can use it this way. But whitelisting a PASS only >because it's a PASS is no long term strategy: > > "v=spf1 +exists:{ir}.comcast.blackholes.us -all" > > > See above. It actually IS very good for AOL because of all our other reputation based logic. Perhaps not every ISP can build this, but we do have one. Of course many 3rd party products are out there that do what we do...SenderBase (volume/bounces), SpamCop (complaints), Spamnet (complaints), etc. >>Back to my day job :-) >> >> > >Be careful with mail from these comcast IPs, bye, Frank > > > > -- Carl Hutzler Director, Host Mail Development America Online cdhutzler@aol.com 703.265.5521 work 703.915.6862 cell From owner-ietf-mxcomp@mail.imc.org Thu May 26 07:57:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22311 for ; Thu, 26 May 2005 07:57:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QBejbA068609; Thu, 26 May 2005 04:40:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QBejTa068608; Thu, 26 May 2005 04:40:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from s2umail01.exmplar.com (s2umail01.exmplar.com [65.196.69.133]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QBeiEt068598 for ; Thu, 26 May 2005 04:40:44 -0700 (PDT) (envelope-from Asukhenko@Exmplar.com) Received: from unknown (HELO s2umail01.shop2u.com) (10.2.1.11) by s2umail01.exmplar.com with ESMTP; 26 May 2005 11:40:39 +0000 X-IronPort-AV: i="3.93,138,1114992000"; d="scan'208"; a="395787:sNHT26858736" Received: by S2U.LOCAL with Internet Mail Service (5.5.2657.72) id ; Thu, 26 May 2005 07:47:45 -0400 Message-ID: <114DE040D7A6524E9C3B000F47CCD8BD0C450C1A@S2U.LOCAL> From: "Sukhenko, Alex" To: Carl Hutzler , nobody@xyzzy.claranet.de Cc: ietf-mxcomp@imc.org Subject: RE: SPF PASS (was: "If you believe that the SPF concept is fundam entally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/") Date: Thu, 26 May 2005 07:47:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sorry if I am jumping on mid stream and missing the main point but SPF was suppose to be the first step and then next would be reputation. BTY I am very pleased with SenderBase (even catches Comcast zombies) I would be curious to know if anyone else is? I also noticed that some corp. at least one Kraft, is rejecting email if your sending IP is not one of your MX IPs: "v=spf1 mx ?all" ---------------------------------------- Alex Sukhenko CTO Exmplar 3900 Jermantown Road Fairfax, VA 20330 703 273 2311 x232 - phone 703 654 6588 - fax -----Original Message----- From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Carl Hutzler Sent: Thursday, May 26, 2005 7:21 AM To: nobody@xyzzy.claranet.de Cc: ietf-mxcomp@imc.org Subject: Re: SPF PASS (was: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/") nobody@xyzzy.claranet.de wrote: >Carl Hutzler wrote: > > > >>Is this use of SPF flawed? >> >> >[...] > > >>If the [connecting IP] = [SPF record] then "trust it >>more/whitelist" >> >> > >It's perfectly possible for a spammer to get a PASS. You >wouldn't whitelist a spammer. But it's impossible for a >spammer to pretend to be me, he'd get a FAIL (in my case). > >Unless I'm this spammer of course. > > > Actually, we DO WHITELIST SPAMMERS. I mean it happens. We don't want it to happen a lot, but it does. See we also monitor everyone on the WL very closely via volume, complaint, and bounce rates. So while a spammer could get onto the whitelist, they won't be for long. And a new spammer will have very low limits placed on how much they can send via a simple SPF=whitelist type method. Now if they prove once on the SPF=whitelist that they are a good sender, we would bump up their rate limits....or if they contact us to get "accredited" via our postmaster.aol.com webpage where you can simply ask to be on the whitelist, we might let them in with higher limits on day 1. We do this of course for well known organizations. >>valuable reverse MX records which cover well over 95% of >>the email traffic on the internet today. >> >> > >Is that a guess ? 95% is a rather high number. > > > OK, 85%. Is that better? Still beats the 80/20 rule easily. How much mail is not sent directly from the sending ISP to the destination ISP. For AOL it is a small number. >>Perhaps SPF should be updated to have the above logic. >> >> > >You can use it this way. But whitelisting a PASS only >because it's a PASS is no long term strategy: > > "v=spf1 +exists:{ir}.comcast.blackholes.us -all" > > > See above. It actually IS very good for AOL because of all our other reputation based logic. Perhaps not every ISP can build this, but we do have one. Of course many 3rd party products are out there that do what we do...SenderBase (volume/bounces), SpamCop (complaints), Spamnet (complaints), etc. >>Back to my day job :-) >> >> > >Be careful with mail from these comcast IPs, bye, Frank > > > > -- Carl Hutzler Director, Host Mail Development America Online cdhutzler@aol.com 703.265.5521 work 703.915.6862 cell From owner-ietf-mxcomp@mail.imc.org Thu May 26 08:39:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25331 for ; Thu, 26 May 2005 08:39:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QCK3dj075370; Thu, 26 May 2005 05:20:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QCK3nV075369; Thu, 26 May 2005 05:20:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QCK1Pu075330 for ; Thu, 26 May 2005 05:20:01 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DbHIe-0004ZZ-DH for ietf-mxcomp@imc.org; Thu, 26 May 2005 14:17:20 +0200 Received: from c-134-89-89.hh.dial.de.ignite.net ([62.134.89.89]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 May 2005 14:17:20 +0200 Received: from nobody by c-134-89-89.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 May 2005 14:17:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: SPF PASS Date: Thu, 26 May 2005 14:13:45 +0200 Organization: Lines: 42 Message-ID: <4295BD79.356A@xyzzy.claranet.de> References: <1117065074.14235.145.camel@SJC-Office-DHCP-156.mail-abuse.org> <200505260302.49515.bulk@mehnle.net> <42952544.1050702@aol.com> <4295ADA1.2343@xyzzy.claranet.de> <4295B105.1030103@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-89-89.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Carl Hutzler wrote: > we also monitor everyone on the WL very closely So you have PASS => assume WHITE until proven BLACK. Yes, that's a better idea than C/R systems based on PASS. postmaster@aol might still get some of these obscure "rebounces" from me with a subject like... Erroneous spam bounce to forged address - please use a filter and/or SPF ...but so far "my" spammers behave and gave up to forge my FAIL-protected vanity domain. [95% of the mails with a SPF policy] >> Is that a guess ? 95% is a rather high number. > OK, 85%. Is that better? Any number is fine, I only wanted to know whether I should now troll various IETF lists with "Carl said 95% of the mail traffic already has v=spf1 policies" Such hype is harmful if it's not true, see John's ongoing rants about the infamous spf.pobox site - it doesn't help when I say that I didn't link to it for almost a year now, or that the SPF Council tried to fix it for about five months - as long as this didn't happen it's a weak spot. SPF is no FUSSP. FUSSPs are stupid, like a perpetuum mobile. > SenderBase (volume/bounces), SpamCop (complaints), > Spamnet (complaints), etc. I'm not very happy with SC allowing "misdirectred bounces" to be reported without a (potential) FAIL. Squeeze out all bounces isn't the plan. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Thu May 26 09:12:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27272 for ; Thu, 26 May 2005 09:12:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QCpPll085102; Thu, 26 May 2005 05:51:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QCpPhp085101; Thu, 26 May 2005 05:51:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from aismt07p.bellsouth.com (aismt07p.bellsouth.com [139.76.165.213]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QCpOpE085094 for ; Thu, 26 May 2005 05:51:25 -0700 (PDT) (envelope-from damon.sauer@bellsouth.com) Received: from ([90.152.52.46]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.40293361; Thu, 26 May 2005 08:50:55 -0400 Importance: normal Received: from 01AL10015010045.ad.bls.com ([90.152.5.71]) by 01al10015010118.ad.bls.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 May 2005 07:50:55 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Subject: RE: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http: //www.imc.org/ietf-mxcomp/" Date: Thu, 26 May 2005 07:50:54 -0500 Message-ID: Thread-Topic: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http: //www.imc.org/ietf-mxcomp/" Thread-Index: AcVhmUKfTOrjbACiTlSdEPx0wiJamQAWDVIQ From: "Sauer, Damon" To: "John Levine" , Cc: X-OriginalArrivalTime: 26 May 2005 12:50:55.0290 (UTC) FILETIME=[8E5561A0:01C561F1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4QCpPpE085096 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Please see: http://www.virusbtn.com/articles/spambulletin/asrg/2004/10_4.xml Regards, Damon Sauer > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of John Levine > Sent: Wednesday, May 25, 2005 10:15 PM > To: ietf-mxcomp@imc.org > Cc: julian@mehnle.net > Subject: Re: "If you believe that the SPF concept is > fundamentally flawed, please subscribe at http: > //www.imc.org/ietf-mxcomp/" > > > > >> Contrary to the promotions, SPF will not stop spam. > > > >Who is promoting SPF as an anti-spam solution? I'd really like to > >know. > > Let's take a look at http://spf.pobox.org. Hey, look what it says: > > SPF is ushering in a new set of anti-spam systems, where email is > spam unless proven otherwise. > > If history is any guide, some SPF fan will write back in a > huff and say "That doesn't say SPF is an anti-spam solution! > It just says that SPF is holding a flashlight and will lead > the actual anti-spam solutions to their seats!" > > This kind of disingenuous doubletalk has characterized SPF > advocacy since its beginning, and is one of the many reasons > that the mainstream e-mail tech community holds SPF in > disdain. That along with its egregious design mistakes and > its irreparably enormous error rate, of course. > > SPF can help whitelist mail from fixed source senders you > already know. That's what AOL uses it for, and it's an > adequate if overly complex means to that end. If the SPF > crowd promoted it for that purpose, I don't think anyone > would have a problem with it. But they don't and the smoke > long ago became unbreathable. > > Regards, > John Levine, johnl@iecc.com, Primary Perpetrator of "The > Internet for Dummies", Information Superhighwayman wanna-be, > http://www.johnlevine.com, Mayor "A book is a > sneeze." - E.B. > White, on the writing of Charlotte's Web > > ***** "The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers." 118 From owner-ietf-mxcomp@mail.imc.org Thu May 26 09:33:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28525 for ; Thu, 26 May 2005 09:33:48 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QDFxQf088960; Thu, 26 May 2005 06:15:59 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QDFxUf088959; Thu, 26 May 2005 06:15:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QDFvgW088934 for ; Thu, 26 May 2005 06:15:58 -0700 (PDT) (envelope-from SRS0=4JPp0DKG=UB=asarian-host.net=admin@asarian-host.net) Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) (authenticated bits=0) by mail.asarian-host.net (8.13.4/8.13.4) with ESMTP id j4QDFuxG048080 for ; Thu, 26 May 2005 15:15:56 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: sender IP is authenticated by a trusted mechanism) receiver=asarian-host.net; client-ip=sender IP; envelope-from=; helo=asarian-host; Message-Id: <200505261315.j4QDFtoB048070@asarian-host.net> Date: Thu, 26 May 2005 13:15:56 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: RE: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/" X-Trace: 49BjHqiC814h02RsM3g4YX/gAjZdXNmOJgBAj6tz8CJEpL0Kt/TNWtyXnSMkSE5f7ApdijGgMf6htKJU7m0dNg== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: "'MARID'" MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <200505260302.49515.bulk@mehnle.net> X-Auth: Asarian-host PGP signature iQEVAwUAQpXMDDFqW1BleBN9AQFRbwf/X0CTOEXKdGTf6oRSxOTf5Q6RGSpDqYgT i83njhtuieSWPwI66VPb8RK+S0Kiejawl/IWm3Yue75GEuk5hO0NQcdd5wVXDxus jBjMHpucOyBDtePrsmspzOGCL6Q2ltrBya2QR8cbJT4Y6iMeSGwHuIbaQcghIHeZ nO5pS4HE89mgdulpir/f1OW6Fu3IxOWqlI4ni9w1MU7XdaGPwbYvCevdW7Nn4DNP jQZ8U20nw+/6jSBGetoXRnSTJkxgPu5X2VAN7We4qjxznnMWuY4wYt+B9kq5JKfU qNiWv+bTxCcZXhVJxKa7u3alBdOsAbLM0NUEVFDMKTzDRvjlcmZklw== =9++h Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Douglas Otis wrote: > Contrary to the promotions, SPF will not stop spam. This is typically one of the noob objections. I will show you why, in the larger scheme of things, SPF most certainly helps the fight against spam. > ... and a slew of modification made to every email client. You got yourself confused with the thingy from Redmond, didn't ya? SPF is inter-MTA based, and requires no changes to email clients whatso-frickin-ever. > I can not accept the premise there are no serious concerns related to > publishing SPF records. No scheme without a reputation assessment will > prevent email abuse. How poor, I must say, is your understanding of SPF. Especially so, since SPF actually greatly helps the reputation assessment! SPF 'funnels', as it were, the use of domain names through specified, authorized relays. Once you have 'locked in' the authorized use of an SPF-protected domain name, you can then confidently consult a reputation service for that domain. To give an example, with SPF, I can now confidently query: aol.com.rating.reputationservice.com > Abusers are among the first to adopt changes offering greater access. Which example allows me to counter the ever recurring noob-objection: "But spammers can publish SPF records too, and so 'bypass' security by getting a PASS!" Counter, because, due to the 'funneling' effect I just spoke of, spammers will gradually be forced to use only their own domain names. At which point they can be block-listed by domain name even. To give an example again, say, a spammer registered "spammer.com", and published SPF records to produce a "pass". With SPF, I can now confidently query: spammer.com.rating.reputationservice.com You see? Causing a "pass", the spammer has only achieved to hang the noose around his own, identified neck! This 'bypass', as noobs call it, is an intended, and desired, effect of SPF. And thus, SPF helps to facilitate the return of domain name block lists and/or domain name based reputation databases. And a domain name based reputation database has great advantages. For one, because the maintainer of said database no longer has to bother with ever-changing IP addresses. That is the beauty of SPF: the domain owners themselves define the authorized IP addresses; the reputation database just lists domain names; and the one making the query does the SPF query for domain X against the connecting IP address to see whether the relay is actually authorized to use the identity. To sum it up: 1): Spammers causing their registered domains to "pass", only identify and set themselves up to be block-listed. 2): Email sent with reputable domains, used without authorization by spammers, are protected -- hence exempt from erroneously being counted towards spam and bad reputation! - Mark System Administrator Asarian-host.org --- "If you were supposed to understand it, we wouldn't call it code." - FedEx From owner-ietf-mxcomp@mail.imc.org Thu May 26 10:01:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29950 for ; Thu, 26 May 2005 10:01:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QDeLxx002167; Thu, 26 May 2005 06:40:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QDeLd1002166; Thu, 26 May 2005 06:40:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from bra.gulbrandsen.priv.no (bra.gulbrandsen.priv.no [212.125.101.197]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4QDeJx1002159 for ; Thu, 26 May 2005 06:40:20 -0700 (PDT) (envelope-from arnt@gulbrandsen.priv.no) Received: by bra.gulbrandsen.priv.no (Postfix, from userid 1000) id 561341A6E3; Thu, 26 May 2005 15:40:18 +0200 (CEST) Received: from prosecco.oryx.com (prosecco.oryx.com [217.19.171.140]) by bra.gulbrandsen.priv.no (Postfix) with SMTP id 1A4821A6C8; Thu, 26 May 2005 15:40:12 +0200 (CEST) Message-Id: <058XYMtydgmnXkuu2syXnA.md5@prosecco.oryx.com> Date: Thu, 26 May 2005 15:39:31 +0200 From: Arnt Gulbrandsen To: ietf-mxcomp@imc.org Subject: Re: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/" Cc: Mark References: <200505261315.j4QDFtoB048070@asarian-host.net> In-Reply-To: <200505261315.j4QDFtoB048070@asarian-host.net> Content-Type: text/plain; format=flowed MIME-Version: 1.0 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mark writes: > SPF is inter-MTA based, and requires no changes to email clients > whatso-frickin-ever. The first time I looked at SPF was because I wanted to ensure that an email client was okay. Specifically, I wanted to check outgoing mail from a roadwarrior machine, and warn the user before sending any mail that would likely fail. That job wasn't so easy. Not so easy. Arnt From owner-ietf-mxcomp@mail.imc.org Thu May 26 10:21:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02239 for ; Thu, 26 May 2005 10:21:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QE28u5004157; Thu, 26 May 2005 07:02:08 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QE28Yw004156; Thu, 26 May 2005 07:02:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QE26TG004148 for ; Thu, 26 May 2005 07:02:07 -0700 (PDT) (envelope-from SRS0=4JPp0DKG=UB=asarian-host.net=admin@asarian-host.net) Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) (authenticated bits=0) by mail.asarian-host.net (8.13.4/8.13.4) with ESMTP id j4QE25dc049884 for ; Thu, 26 May 2005 16:02:05 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: sender IP is authenticated by a trusted mechanism) receiver=asarian-host.net; client-ip=sender IP; envelope-from=; helo=asarian-host; Message-Id: <200505261402.j4QE25pq049874@asarian-host.net> Date: Thu, 26 May 2005 14:02:05 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: RE: "If you believe that the SPF concept is fundamentally flawed,please subscribe at http://www.imc.org/ietf-mxcomp/" X-Trace: D0vkbRvYhApMpFgW8pVxf+Kyqsc2Blt1DDiKXhZAfaG+8EE7uAlnRZdSQVsneTL8IFQc9l1JQdbpn/SfKWB+Cw== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <058XYMtydgmnXkuu2syXnA.md5@prosecco.oryx.com> X-Auth: Asarian-host PGP signature iQEVAwUAQpXW3TFqW1BleBN9AQH5vQf9FG0G9DUHAqtmTTmjRLjuCnI0X3oeD9v/ peD1ZYb8DeRHyh9aMu8aKTYtRnnUpPDs+/IbZVAsFXFvPD6ZZTGq4IDb41Pu64M+ yPsLDfSiSJBjQp7I15mSMkcDxm9c/V4H1CWgeC5z+S+nqv3URUScS/MpMgdr4duF mLjuOdG6Bzni9Xn3/QRy3TwBQA/zqmQm9MYHlWGqMgKOlN0QOgoVkt4PBDkV7QqN eZPKmUH+1we7JeAtiVV2d3wQX5qP+0GrXpjT0XuF6Vxp90Oioy4iM5yGpD1zGCRp LNtQNkWNGrZ5LAx0cTnEGPS0mlQOxp7lPlICFZn1UmMVu0jX+Itklg== =PSnq Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Arnt Gulbrandsen [mailto:arnt@gulbrandsen.priv.no] > Sent: donderdag 26 mei 2005 15:41 > To: ietf-mxcomp@imc.org > Cc: Mark > Subject: Re: "If you believe that the SPF concept is > fundamentally flawed,please subscribe at > http://www.imc.org/ietf-mxcomp/" > > > > Mark writes: > > SPF is inter-MTA based, and requires no changes to email clients > > whatso-frickin-ever. > > The first time I looked at SPF was because I wanted to ensure that an > email client was okay. Specifically, I wanted to check outgoing mail > from a roadwarrior machine, and warn the user before sending any mail > that would likely fail. > > That job wasn't so easy. Not so easy. It is up to the ISP/MTA how to deal with their roaming users. Typically, SMTP AUTH / DRAC is used (that has nothing to do with SPF even, but everything with your ISP not being an open relay and still allowing its customers roaming access). So, if you send mail, from the road, through the relay you authorized, then that relay should SPF "pass" you (provided you use the correct domain name, of course). Sending through someone else's, unauthorized relay may, indeed, present a problem on the receiving end if they check SPF (and thus would reject your mail). But that is the whole point: either we allow everyone to use every domain name through every relay (they have access to), or we specify authorized relays. If we do the latter, then naturally doing the former will no longer work. I believe that is a good thing. It will take some mentality adjusting, though; like way back when, when people said: "I used to be able to send through every SMTP server I wanted; and now, dangit, I can only use the ones I have been given access to." That change, too, was a good thing. - Mark System Administrator Asarian-host.org --- "If you were supposed to understand it, we wouldn't call it code." - FedEx From owner-ietf-mxcomp@mail.imc.org Thu May 26 11:03:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05002 for ; Thu, 26 May 2005 11:03:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QEhSkK017147; Thu, 26 May 2005 07:43:28 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QEhSra017146; Thu, 26 May 2005 07:43:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from zak.ecotroph.net (zak.hxr.us [216.93.167.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QEhS8d017140 for ; Thu, 26 May 2005 07:43:28 -0700 (PDT) (envelope-from andy@hxr.us) Received: from [10.131.244.246] ([::ffff:216.168.239.87]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Thu, 26 May 2005 10:43:27 -0400 id 000FBA1F.4295E08F.00000F11 In-Reply-To: <114DE040D7A6524E9C3B000F47CCD8BD0C450C1A@S2U.LOCAL> References: <114DE040D7A6524E9C3B000F47CCD8BD0C450C1A@S2U.LOCAL> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <55a5ed639e56e4e706aef879165b476e@hxr.us> Content-Transfer-Encoding: 7bit Cc: Carl Hutzler , ietf-mxcomp@imc.org, nobody@xyzzy.claranet.de From: Andrew Newton Subject: Re: SPF PASS (was: "If you believe that the SPF concept is fundam entally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/") Date: Thu, 26 May 2005 10:43:26 -0400 To: "Sukhenko, Alex" X-Mailer: Apple Mail (2.619.2) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On May 26, 2005, at 7:47 AM, Sukhenko, Alex wrote: >>> valuable reverse MX records which cover well over 95% of >>> the email traffic on the internet today. >>> >>> >> >> Is that a guess ? 95% is a rather high number. >> >> >> > OK, 85%. Is that better? Still beats the 80/20 rule easily. How much > mail is not sent directly from the sending ISP to the destination ISP. > For AOL it is a small number. So why aren't more people publishing very assertive SPF records ending in -all and why aren't more people only accepting mail that has a PASS? Like Carl, I use SPF but not in the manner prescribed by the SPF documents. I think there would be fewer detractors of SPF if more emphasis were placed on the "Framework" portion of the spec. That's not to say that the work currently underway by Wayne is unimportant. -andy From owner-ietf-mxcomp@mail.imc.org Thu May 26 11:55:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08043 for ; Thu, 26 May 2005 11:55:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QFYNrr022612; Thu, 26 May 2005 08:34:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QFYNEx022611; Thu, 26 May 2005 08:34:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QFYMvd022605 for ; Thu, 26 May 2005 08:34:22 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j4QFYKis000415; Thu, 26 May 2005 08:34:21 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j4QFYKQP000412; Thu, 26 May 2005 08:34:20 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 26 May 2005 08:34:20 -0700 (PDT) From: "william(at)elan.net" To: Andrew Newton cc: ietf-mxcomp@imc.org Subject: Re: SPF PASS (was: "If you believe that the SPF concept is fundam entally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/") In-Reply-To: <55a5ed639e56e4e706aef879165b476e@hxr.us> Message-ID: References: <114DE040D7A6524E9C3B000F47CCD8BD0C450C1A@S2U.LOCAL> <55a5ed639e56e4e706aef879165b476e@hxr.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 26 May 2005, Andrew Newton wrote: >> OK, 85%. Is that better? Still beats the 80/20 rule easily. How much >> mail is not sent directly from the sending ISP to the destination ISP. >> For AOL it is a small number. > So why aren't more people publishing very assertive SPF records ending in > -all and why aren't more people only accepting mail that has a PASS? 85% of email traffic (percent counted based on single messages) may well be < 50% of email senders (percent counted based on individual authors) and may be < 10% of email sender domains (percent counted based on domains of individual senders). Its that last number that is likely to be crucial because the first 2 numbers involve people user communicates with most often or who are on the same net and those are likely to already be on their whitelist (if they have it), but user does not expect mail from others to be rejected or otherwise such user would already be using whitelisting-only setup. > Like Carl, I use SPF but not in the manner prescribed by the SPF documents. Unless I'm mistaken, you use it exactly in the manner prescribed by the EHLO part of the spec, you're just downgrade results from MAILFROM check. As I said long ago, EHLO should be totally separate document with separate recommendations about its use (like CSV) and separate recommendations about setting up records (because records should be a lot more precise and consist of one or couple of "a" instead of entire ip blocks and includes). And for each scope like EHLO it should be up to receiver if it wants to use just one scope or several in combination with optional document that is available describing guidelines for doing combined checks. > I think there would be fewer detractors of SPF if more emphasis were placed > on the "Framework" portion of the spec. Sure, I'd love to get started on the "Framework" (aka UnifiedSPF), if only we did not have well known political factors distracting us from the work. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Thu May 26 12:35:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11016 for ; Thu, 26 May 2005 12:35:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QGEQBb027871; Thu, 26 May 2005 09:14:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QGEQKH027870; Thu, 26 May 2005 09:14:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QGEPfI027860 for ; Thu, 26 May 2005 09:14:25 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:39832) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1DbKzx-0002HW-18 (Exim 4.51) (return-path ); Thu, 26 May 2005 17:14:17 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1DbKzx-0002gu-9x (Exim 4.43) (return-path ); Thu, 26 May 2005 17:14:17 +0100 Date: Thu, 26 May 2005 17:14:17 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: Carl Hutzler cc: ietf-mxcomp@imc.org Subject: SPF and HELO, was Re: SPF PASS (was: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/") In-Reply-To: <4295EDCF.4020707@aol.com> Message-ID: References: <114DE040D7A6524E9C3B000F47CCD8BD0C450C1A@S2U.LOCAL> <55a5ed639e56e4e706aef879165b476e@hxr.us> <4295EDCF.4020707@aol.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 26 May 2005, Carl Hutzler wrote: > > I wish there was a way to utilize the relatively large number of SPF records > in a technology like CSV. It seemed to me at one point that there was some promise that it would be possible to write an SPF record which applied only to HELO or only to PRA or only to the return path. However divergent SPF/SenderID implementations and specifications have horribly muddied the waters and I'm not sure it's possible to do this now and expect any kind of reliable interoperability. Disaster. Tony. -- f.a.n.finch http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. From owner-ietf-mxcomp@mail.imc.org Thu May 26 12:39:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11338 for ; Thu, 26 May 2005 12:39:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QGKnVF028577; Thu, 26 May 2005 09:20:49 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QGKn05028575; Thu, 26 May 2005 09:20:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QGKkEo028536 for ; Thu, 26 May 2005 09:20:46 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j4QGKhR4001044; Thu, 26 May 2005 09:20:43 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j4QGKguY001041; Thu, 26 May 2005 09:20:43 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 26 May 2005 09:20:42 -0700 (PDT) From: "william(at)elan.net" To: Carl Hutzler cc: Andrew Newton , ietf-mxcomp@imc.org Subject: Re: SPF PASS (was: "If you believe that the SPF concept is fundam entally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/") In-Reply-To: <4295EDCF.4020707@aol.com> Message-ID: References: <114DE040D7A6524E9C3B000F47CCD8BD0C450C1A@S2U.LOCAL> <55a5ed639e56e4e706aef879165b476e@hxr.us> <4295EDCF.4020707@aol.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 26 May 2005, Carl Hutzler wrote: > I wish there was a way to utilize the relatively large number of SPF records > in a technology like CSV. We could easily write EHLO guidelines for SPF record checking and publishing as separate document, kind of like BCP. In fact I'll keep this in mind and bring it up on spf-discuss when things are a little more calm from current spf-classic draft discussions. ---- BTW - while we're talking about it, here is an algorithm for you to test: 1. Check if EHLO name is delegated in DNS, if so go to #2, otherwise skip to the end with result of UNKNOWN 2. Check if EHLO name has corresponding "A" record and if so go to #3 else go to #4 3. Check if "A" record points to the ip of SMTP client, if so result is PASS, smile and skip to the end. Otherwise proceed to #4 4. Check if EHLO name has an SPF record. If it does, go to #5, otherwise go to #7 5. Try to do SPF test against EHLO name and client ip. If result is SPF pass, take it as PASS, smile and skip to the end. If result is SPF fail, take it as FAIL and skip to the end If result is SPF softfail, go to #6 If result is SPF neutral or something else, take it as UNKNOWN and skip to the end 6. Check if EHLO name has one or more MX record. If it has none, then result is FAIL, skip to the end. Otherwise result is UNKNOWN. [If it has an MX, its good indication the name is used as domain and not as a host - most hosts do not have assigned MX] 7. If EHLO name is not TLD then cut down the first component of the name (i.e. for "host.example.com", cut down "host" to make it "example.com"). Take this new cut name as if it was original EHLO name and proceed to #4 8. THE END -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Thu May 26 13:04:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13459 for ; Thu, 26 May 2005 13:04:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QGiF6j033937; Thu, 26 May 2005 09:44:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QGiFNF033936; Thu, 26 May 2005 09:44:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QGiEl2033929 for ; Thu, 26 May 2005 09:44:14 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j4QGhfv1001396; Thu, 26 May 2005 09:43:41 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j4QGhfI0001393; Thu, 26 May 2005 09:43:41 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 26 May 2005 09:43:41 -0700 (PDT) From: "william(at)elan.net" To: Tony Finch cc: Carl Hutzler , ietf-mxcomp@imc.org Subject: Re: SPF and HELO, was Re: SPF PASS (was: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/") In-Reply-To: Message-ID: References: <114DE040D7A6524E9C3B000F47CCD8BD0C450C1A@S2U.LOCAL> <55a5ed639e56e4e706aef879165b476e@hxr.us> <4295EDCF.4020707@aol.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 26 May 2005, Tony Finch wrote: >> I wish there was a way to utilize the relatively large number of SPF records >> in a technology like CSV. > > It seemed to me at one point that there was some promise that it would be > possible to write an SPF record which applied only to HELO or only to PRA > or only to the return path. However divergent SPF/SenderID implementations > and specifications have horribly muddied the waters and I'm not sure it's > possible to do this now and expect any kind of reliable interoperability. > Disaster. At the end of MARID we started on the path towards unified spf and multiple scopes. I'd not have been surprised if HELO was next scope introduced and while I recognize contributions made by CSV people and hard work they have put in their documents, a common syntax is better for all and in the end, I believe their work would have been adoptable as "restricted profile" SPF record (using "a" in place of SRV) as documentation for HELO scope. IESG did not do us (I mean everyone who is interest in better email anti-spoofing and security technologies) any favors by closing down MARID when we finally started getting somewhere even if we were behind on the deadline, other WGs are years behind in their work and do not get disbanded (or need I mention USEFOR perhaps...) And not that it matters, but AOL did not help either by agreeing to support SID with use of spf1 only records (which brought political crisis and strong unhappiness in spf community and stalled further work on unified spf) - instead you should have pushed for quickly having rfc (even if its not 100% perfect) that documents current spf1 with all further work continuing on "spf2" with more comprehensive per-scope documentation and usage guidelines. Oh well, enough of history... Lets hope we can salvage at least some of what we had worked for in the future even if it will not happen quickly. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Thu May 26 13:26:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14895 for ; Thu, 26 May 2005 13:26:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QH3mpV037115; Thu, 26 May 2005 10:03:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QH3mne037114; Thu, 26 May 2005 10:03:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.schlitt.net (schlitt.net [67.52.51.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QH3lkM037108 for ; Thu, 26 May 2005 10:03:48 -0700 (PDT) (envelope-from wayne@schlitt.net) Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1DbLli-0001rw-2S for ietf-mxcomp@imc.org; Thu, 26 May 2005 12:03:47 -0500 To: "IETF MARID WG" References: <114DE040D7A6524E9C3B000F47CCD8BD0C450C1A@S2U.LOCAL> <55a5ed639e56e4e706aef879165b476e@hxr.us> <4295EDCF.4020707@aol.com> From: wayne Mail-Copies-To: nobody Reply-To: "IETF MARID WG" Content-Type: text/plain; charset=US-ASCII Date: Thu, 26 May 2005 12:03:37 -0500 In-Reply-To: (Tony Finch's message of "Thu, 26 May 2005 17:14:17 +0100") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: SPF and HELO, was Re: SPF PASS (was: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/") X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on backbone.schlitt.net X-Spam-Status: No, score=-6.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In Tony Finch writes: > On Thu, 26 May 2005, Carl Hutzler wrote: >> >> I wish there was a way to utilize the relatively large number of SPF records >> in a technology like CSV. > > It seemed to me at one point that there was some promise that it would be > possible to write an SPF record which applied only to HELO or only to PRA > or only to the return path. Yes, at one point there was the ability to limit SPF version 1 records to only certain scopes, but the scope= modifier was removed in the fall of 2003. At the time, we really couldn't think of a reliable way of applying SPF records to the 2822.From: header, and it was thought that distinguishing between the 2821.MAILFROM and 2821.HELO identities was not needed. After widespread experimentation with SPF started in Dec of 2003, it made changes to the SPF specification very hard. > However divergent SPF/SenderID implementations > and specifications have horribly muddied the waters and I'm not sure it's > possible to do this now and expect any kind of reliable interoperability. > Disaster. The goal of the latest SPF-classic (e.g original SPF) I-D is to document what exists, not to try and create a new SPF protocol. We have worked very hard to try and keep as much of the semantics of the draft-mengwong-spf-0[01] documents as practical. It is true that the MARID I-Ds[*] define a newer protocol with updated semantics that include things like the return of scopes to SPF. These I-Ds also call for a new version number to be used, which is good, but then these I-Ds say that the new semantics should be applied to SPFv1 records, which is REALLY bad. I have asked the IESG to block the publication of the MARID I-Ds due to the harm that will cause to the existing SPFv1 deployment. So far, the IESG has not agreed with this and the incompatible MARID I-Ds are going forward. -wayne [*] At one time, Andy asked the PTB whether the existing SenderID trademark would cause legal problems for the IETF/ISOC if we published I-Ds using that trademark. Andy came back and said the risk is too high and that SenderID shouldn't be used in IETF RFCs. Until such time that I hear that the PTB of the IETF have changed their mind, I am trying to avoid the use of "SenderID" when referencing the MARID I-Ds. From owner-ietf-mxcomp@mail.imc.org Thu May 26 13:26:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14977 for ; Thu, 26 May 2005 13:26:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QH8evF037539; Thu, 26 May 2005 10:08:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QH8eao037538; Thu, 26 May 2005 10:08:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4QH8dPn037532 for ; Thu, 26 May 2005 10:08:40 -0700 (PDT) (envelope-from prvs=johnl/09290505df@iecc.com) Received: (qmail 3090 invoked by uid 100); 26 May 2005 17:08:38 -0000 Date: 26 May 2005 17:08:38 -0000 Message-ID: <20050526170838.3089.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: SPF and HELO, was Re: SPF PASS (was: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/") In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA Cc: dot@dotat.at Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >> I wish there was a way to utilize the relatively large number of SPF records >> in a technology like CSV. Yeah. Too bad that among SPF's many flaws is that it completely confuses the HELO domain and the MAIL FROM domain (and on a bad day, the domains in From:, Sender:, Resent-From:, and Resent-Sender:.) >It seemed to me at one point that there was some promise that it >would be possible to write an SPF record which applied only to HELO >or only to PRA or only to the return path. SPF 2.0 was supposed to let you specify which contexts each record is supposed to apply to, but I agree that it'll never get any traction. From owner-ietf-mxcomp@mail.imc.org Thu May 26 13:28:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15123 for ; Thu, 26 May 2005 13:28:24 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QHAiDe037721; Thu, 26 May 2005 10:10:44 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QHAigr037720; Thu, 26 May 2005 10:10:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from xuxa.iecc.com (xuxa.iecc.com [208.31.42.42]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4QHAhGR037713 for ; Thu, 26 May 2005 10:10:44 -0700 (PDT) (envelope-from prvs=johnl/09290505df@iecc.com) Received: (qmail 5260 invoked by uid 100); 26 May 2005 17:10:42 -0000 Date: 26 May 2005 17:10:42 -0000 Message-ID: <20050526171042.5259.qmail@xuxa.iecc.com> From: John Levine To: ietf-mxcomp@imc.org Subject: Re: SPF PASS (was: "If you believe that the SPF concept is fundam entally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/") In-Reply-To: Organization: I.E.C.C., Trumansburg NY USA Cc: william@elan.net Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >We could easily write EHLO guidelines for SPF record checking and >publishing as separate document, kind of like BCP. In fact I'll >keep this in mind and bring it up on spf-discuss when things are >a little more calm from current spf-classic draft discussions. We could, but since you can't tell whether the list of addresses in an SPF record is supposed to apply to the EHLO address or the MAIL FROM address or one of the message header addresses, what's the point? The domain names in my EHLOs is completely disjoint from the set in my MAIL FROM and mail headers. How is SPF going to handle that? From owner-ietf-mxcomp@mail.imc.org Thu May 26 13:30:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15274 for ; Thu, 26 May 2005 13:30:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QHDIN0037929; Thu, 26 May 2005 10:13:18 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QHDIdS037928; Thu, 26 May 2005 10:13:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.schlitt.net (schlitt.net [67.52.51.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QHDHtu037922 for ; Thu, 26 May 2005 10:13:17 -0700 (PDT) (envelope-from wayne@schlitt.net) Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1DbLuw-000213-Rk for ietf-mxcomp@imc.org; Thu, 26 May 2005 12:13:17 -0500 To: "IETF MARID WG" References: <200505261402.j4QE25pq049874@asarian-host.net> <4295E19E.2040900@aol.com> From: wayne Mail-Copies-To: nobody Reply-To: "IETF MARID WG" Content-Type: text/plain; charset=US-ASCII Date: Thu, 26 May 2005 12:13:10 -0500 In-Reply-To: <4295E19E.2040900@aol.com> (Carl Hutzler's message of "Thu, 26 May 2005 10:47:58 -0400") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: "If you believe that the SPF concept is fundamentally flawed,please subscribe at http://www.imc.org/ietf-mxcomp/" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on backbone.schlitt.net X-Spam-Status: No, score=-6.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <4295E19E.2040900@aol.com> Carl Hutzler writes: > BTW, this issue of allowing someone to send through "someone else's > relay" is a problem for ALL email authentication approaches except > perhaps CSV and BATV. SRS/SES/BATV/ABBS have key distribution key distribution problems similar to DK/IIM when end users try to send through someone else's MTA. I think that if there was an easy solution, someone would have thought of it many years ago. What we have is a bunch of different solutions which require different changes to the current email environment to work. Which one you think is best often depends on your assumptions about the costs and benefits of each solution. -wayne From owner-ietf-mxcomp@mail.imc.org Thu May 26 13:38:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15873 for ; Thu, 26 May 2005 13:38:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QHJrvT038543; Thu, 26 May 2005 10:19:53 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QHJrZ0038542; Thu, 26 May 2005 10:19:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ppsw-7.csi.cam.ac.uk (ppsw-7.csi.cam.ac.uk [131.111.8.137]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QHJqEd038525 for ; Thu, 26 May 2005 10:19:53 -0700 (PDT) (envelope-from fanf2@hermes.cam.ac.uk) X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:57316) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1DbM1I-0000kL-Nu (Exim 4.51) for ietf-mxcomp@imc.org (return-path ); Thu, 26 May 2005 18:19:44 +0100 Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1DbM1I-0005fb-CH (Exim 4.43) for ietf-mxcomp@imc.org (return-path ); Thu, 26 May 2005 18:19:44 +0100 Date: Thu, 26 May 2005 18:19:44 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk To: IETF MARID WG Subject: Re: SPF and HELO, was Re: SPF PASS (was: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/") In-Reply-To: Message-ID: References: <114DE040D7A6524E9C3B000F47CCD8BD0C450C1A@S2U.LOCAL> <55a5ed639e56e4e706aef879165b476e@hxr.us> <4295EDCF.4020707@aol.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 26 May 2005, wayne wrote: > > These I-Ds also call for a new version number to be used, which is good, > but then these I-Ds say that the new semantics should be applied to > SPFv1 records, which is REALLY bad. I strongly agree. This makes it impossible to use SPF's baroqueness to advantage, e.g. by using BATV with stunt DNS servers, and other clever tricks. Tony. -- f.a.n.finch http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. From owner-ietf-mxcomp@mail.imc.org Thu May 26 13:38:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15895 for ; Thu, 26 May 2005 13:38:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QHIO9c038418; Thu, 26 May 2005 10:18:24 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QHIOkA038417; Thu, 26 May 2005 10:18:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.schlitt.net (schlitt.net [67.52.51.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QHINIs038411 for ; Thu, 26 May 2005 10:18:23 -0700 (PDT) (envelope-from wayne@schlitt.net) Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1DbLzq-00029F-0T for ietf-mxcomp@imc.org; Thu, 26 May 2005 12:18:22 -0500 To: "IETF MARID WG" References: <200505260302.49515.bulk@mehnle.net> <200505261315.j4QDFtoB048070@asarian-host.net> From: wayne Mail-Copies-To: nobody Reply-To: "IETF MARID WG" Content-Type: text/plain; charset=US-ASCII Date: Thu, 26 May 2005 12:18:12 -0500 In-Reply-To: (Richard Clayton's message of "Thu, 26 May 2005 17:41:20 +0100") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on backbone.schlitt.net X-Spam-Status: No, score=-6.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In Richard Clayton writes: > Hence, since they still want to spam, they will start sending email with > borrowed domains from borrowed machines... they are already doing the > latter, they don't do the former because there's currently no need. SPF > would, if adopted, provide the evolutionary pressure for them to do so. > > Of course you may feel that if fred@example.com is so dumb as to install > a spam-sending trojan that it serves him right if example.com gets a > really bad reputation. However, if I have a need to swap email with > example.com employees how exactly has SPF improved the situation here ? example.com can quickly update their SPF record to remove the offending IP address from their approved list. -wayne From owner-ietf-mxcomp@mail.imc.org Thu May 26 13:54:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16846 for ; Thu, 26 May 2005 13:54:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QHZWvs054402; Thu, 26 May 2005 10:35:32 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QHZWPv054401; Thu, 26 May 2005 10:35:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ftp.catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4QHZVx9054356 for ; Thu, 26 May 2005 10:35:31 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.1.451.4) for ietf-mxcomp@imc.org; Thu, 26 May 2005 13:36:25 -0400 Received: from ([68.215.118.148]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.1.451.4) with SMTP id 881017187; Thu, 26 May 2005 13:36:24 -0400 Message-ID: <008d01c56219$0ccd9030$6401a8c0@hdev1> From: "Hector Santos" To: "Carl Hutzler" , Cc: "Andrew Newton" , References: <114DE040D7A6524E9C3B000F47CCD8BD0C450C1A@S2U.LOCAL> <55a5ed639e56e4e706aef879165b476e@hxr.us> <4295EDCF.4020707@aol.com> Subject: Addressing Backward Compatibility [was Re: SPF PASS] Date: Thu, 26 May 2005 13:33:32 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Carl Hutzler" Sent: Thursday, May 26, 2005 11:39 AM Subject: Re: SPF PASS > I wish there was a way to utilize the relatively large number of SPF > records in a technology like CSV. > > -Carl The basic issue with all of this is not a specific methodology can work or not work, but rather the basic fact that none of it can be enforced. So even if all the kinks were solved in SPF, CSV, FUZZ, ABC or what have you, SMTP developers, such as yourself, myself and others will still be stuck with still ACCEPTING the non-compliant senders and/or dealing with legacy issues. It doesn't make sense. The only, and I mean only reason I implemented SPF was two reasons: 1) AOL.COM announced support from a domain standpoint. AOL being one of the greatest sources of spam (spoofed or otherwise), we need something from AOL to help all the other victim systems. So once AOL.COM announce SPF support by publishing a SPF domain, we immediately started to implement SPF, and guess what, the AOL announcement also made MICROSOFT jump and in my view, was the reason MARID eventually started 2) SPF would be part of a suite of other methods, in particular ONE method that has no dependency with "new" information being available - this is the CBV, the call back verifier. The CBV is 100% based on the idea that "ok, we don't have much to go on, but at the VERY least, from a SMTP BOUNCE compliancy standpoint, the return path must be valid. It may be spoofed, it may be a zombie, but it must be valid. It can not be junk." So we explored the CBV. I am not saying it is the "answer" but what it proved was one fundamental aspect of the problem we are trying to address: That indeed, the majority, by atleast 60-80% of all transactions are non-compliant from a SMTP standpoint. Period. No ands, ifs or butts. And it should not be a SURPRISE to anyone because it is the reason why we have the problem in the first place. So what's missing from the process? We need an anchor that exist today to address the backward compatibility issue. We don't really have a consensus on what uniquely identifies a MAIL sender or machine that is part of a mail domain. So we can debate, argue left and right, we are still left with the same old issue on how to address backward compatibility. Until someone can address this, all the proposals are for the most part worthless. This is the secret the spammers don't want us to discover and realize, because until we do, they have no reason for them to change or adapt. SPF can work if everyone was forced to use SUBMITTER like idea to address the transitional domain/ip changes. CSV can work if everyone was forced to use reliable client domain name. etc, etc, but as long as it is not "REQUIRED" or enforceable, it is all worthless. So Carl, how can we enforce these proposals? How do I enforce CSV support? No, I am not encouraging "POLICY" discussions. I am talking about how can we automate the framework of a mixed hetergeneous network of systems? I have a few ideas. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com From owner-ietf-mxcomp@mail.imc.org Thu May 26 14:17:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18504 for ; Thu, 26 May 2005 14:17:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QHtbY8059022; Thu, 26 May 2005 10:55:37 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QHtbii059021; Thu, 26 May 2005 10:55:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.schlitt.net (schlitt.net [67.52.51.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QHtaDf059012 for ; Thu, 26 May 2005 10:55:36 -0700 (PDT) (envelope-from wayne@schlitt.net) Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1DbMZr-00031o-6P for ietf-mxcomp@imc.org; Thu, 26 May 2005 12:55:35 -0500 To: "IETF MARID WG" References: <114DE040D7A6524E9C3B000F47CCD8BD0C450C1A@S2U.LOCAL> <55a5ed639e56e4e706aef879165b476e@hxr.us> <4295EDCF.4020707@aol.com> From: wayne Mail-Copies-To: nobody Reply-To: "IETF MARID WG" Content-Type: text/plain; charset=US-ASCII Date: Thu, 26 May 2005 12:55:26 -0500 In-Reply-To: (Tony Finch's message of "Thu, 26 May 2005 18:19:44 +0100") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: SPF and HELO, was Re: SPF PASS (was: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/") X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on backbone.schlitt.net X-Spam-Status: No, score=-6.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In Tony Finch writes: > On Thu, 26 May 2005, wayne wrote: >> >> These I-Ds also call for a new version number to be used, which is good, >> but then these I-Ds say that the new semantics should be applied to >> SPFv1 records, which is REALLY bad. > > I strongly agree. This makes it impossible to use SPF's baroqueness to > advantage, e.g. by using BATV with stunt DNS servers, and other clever > tricks. If you agree that this is really bad, I encourage you to tell iesg@ietf.org about this. I had placed a warning about these problems in the spf-classic I-D submitted early this year, but someone took it upon themselves, without informing either Meng nor me, to remove this warning. In the lastest SPF-classic I-D, the SPF community came up with what I think is a nice paragraph on the subject, with an explict reference to just such stunt DNS server as you describe. (See sections 2.4 and 9.3.1.2) -wayne From owner-ietf-mxcomp@mail.imc.org Thu May 26 14:28:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19269 for ; Thu, 26 May 2005 14:28:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QI33Gb059467; Thu, 26 May 2005 11:03:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QI332P059465; Thu, 26 May 2005 11:03:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QI2wDQ059449 for ; Thu, 26 May 2005 11:03:01 -0700 (PDT) (envelope-from terry@ashtonwoodshomes.com) Received: from [10.243.102.72] ([216.191.52.74]) (authenticated bits=0) by mail.greatgulfhomes.com (8.12.8/8.12.8) with ESMTP id j4QI3dGk008437; Thu, 26 May 2005 14:03:39 -0400 Message-ID: <42960F81.3010706@ashtonwoodshomes.com> Date: Thu, 26 May 2005 14:03:45 -0400 From: Terry Fielder User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Levine CC: ietf-mxcomp@imc.org, dot@dotat.at Subject: Re: SPF and HELO, was Re: SPF PASS References: <20050526170838.3089.qmail@xuxa.iecc.com> In-Reply-To: <20050526170838.3089.qmail@xuxa.iecc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit John Levine wrote: >>>I wish there was a way to utilize the relatively large number of SPF records >>>in a technology like CSV. > > > Yeah. Too bad that among SPF's many flaws is that it completely > confuses the HELO domain and the MAIL FROM domain No it does not. It checks each independently. See my previous post to your question. > (and on a bad day, > the domains in From:, Sender:, Resent-From:, and Resent-Sender:.) SPF never does that, please do not confuse PRA with SPF. > > >>It seemed to me at one point that there was some promise that it >>would be possible to write an SPF record which applied only to HELO >>or only to PRA or only to the return path. > > > SPF 2.0 was supposed to let you specify which contexts each record is > supposed to apply to, but I agree that it'll never get any traction. SPF 2.0 won't, because its tied to PRA. That does not preclude SPF 3.0 using the syntax of proposed SPF2.0, which would superscede SPF1 and really be the second generation of SPF1 (because SPF2.0 was *not* second generation of SPF, it was hijacking to a completely different usage and meaning (PRA)) > > -- Terry Fielder terry@greatgulfhomes.com Associate Director Software Development and Deployment Great Gulf Homes / Ashton Woods Homes Fax: (416) 441-9085 From owner-ietf-mxcomp@mail.imc.org Thu May 26 14:28:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19288 for ; Thu, 26 May 2005 14:28:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QI43s5059553; Thu, 26 May 2005 11:04:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QI4357059552; Thu, 26 May 2005 11:04:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.schlitt.net (schlitt.net [67.52.51.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QI42cA059546 for ; Thu, 26 May 2005 11:04:02 -0700 (PDT) (envelope-from wayne@schlitt.net) Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1DbMi3-0003CU-92 for ietf-mxcomp@imc.org; Thu, 26 May 2005 13:04:02 -0500 To: "IETF MARID WG" References: <20050526171042.5259.qmail@xuxa.iecc.com> From: wayne Mail-Copies-To: nobody Reply-To: "IETF MARID WG" Content-Type: text/plain; charset=US-ASCII Date: Thu, 26 May 2005 13:03:54 -0500 In-Reply-To: <20050526171042.5259.qmail@xuxa.iecc.com> (John Levine's message of "26 May 2005 17:10:42 -0000") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: SPF PASS (was: "If you believe that the SPF concept is fundam entally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/") X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on backbone.schlitt.net X-Spam-Status: No, score=-6.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <20050526171042.5259.qmail@xuxa.iecc.com> John Levine writes: >>We could easily write EHLO guidelines for SPF record checking and >>publishing as separate document, kind of like BCP. In fact I'll >>keep this in mind and bring it up on spf-discuss when things are >>a little more calm from current spf-classic draft discussions. > > We could, but since you can't tell whether the list of addresses in > an SPF record is supposed to apply to the EHLO address or the MAIL FROM > address or one of the message header addresses, what's the point? While far from perfect, it is possible to check the local part to see if it is "postmaster" and use that to distinguish between HELO and MAIL FROM. In order for this to strictly work, you can't send email using postmaster from hosts that you have these kinds of SPF checks. So, you could say: example.com TXT "v=spf1 redirect=%{l}._spf.%{d}" postmaster.example.com TXT "v=spf1 ... HELO policy ..." *.example.com TXT "v=spf1 ... MAIL FROM policy ..." Yes, this very ugly. Yes, if the designers of SPF knew two years ago what we know today, we would have done a lot of things differently. Lacking a time machine, we are kind of stuck with the semantics of SPFv1 records. -wayne From owner-ietf-mxcomp@mail.imc.org Thu May 26 14:31:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19466 for ; Thu, 26 May 2005 14:31:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QI33Dt059466; Thu, 26 May 2005 11:03:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QI33Cg059464; Thu, 26 May 2005 11:03:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QI2xbC059450 for ; Thu, 26 May 2005 11:03:01 -0700 (PDT) (envelope-from terry@ashtonwoodshomes.com) Received: from [10.243.102.72] ([216.191.52.74]) (authenticated bits=0) by mail.greatgulfhomes.com (8.12.8/8.12.8) with ESMTP id j4QHxRGk008145; Thu, 26 May 2005 13:59:27 -0400 Message-ID: <42960E85.7070503@ashtonwoodshomes.com> Date: Thu, 26 May 2005 13:59:33 -0400 From: Terry Fielder User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Levine CC: ietf-mxcomp@imc.org, william@elan.net Subject: Re: SPF PASS References: <20050526171042.5259.qmail@xuxa.iecc.com> In-Reply-To: <20050526171042.5259.qmail@xuxa.iecc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit John Levine wrote: >>We could easily write EHLO guidelines for SPF record checking and >>publishing as separate document, kind of like BCP. In fact I'll >>keep this in mind and bring it up on spf-discuss when things are >>a little more calm from current spf-classic draft discussions. > > > We could, but since you can't tell whether the list of addresses in > an SPF record is supposed to apply to the EHLO address or the MAIL FROM > address or one of the message header addresses, what's the point? Read on to see the point. > > The domain names in my EHLOs is completely disjoint from the set in my > MAIL FROM and mail headers. How is SPF going to handle that? > I believe you will find that the EHLO/HELO is only checked if the MAIL FROM fails. I think I have heard of other implementations where: If the EHLO fails, you check the MAIL FROM, and if that passes then it gets an SPF pass. Either way, it doesn't matter if your EHLO fails (it does on many, maybe even MOST systems), because as long as your MAIL FROM is SPF PASS, then your mails SPF response on the whole is a PASS, and is not negatively affected. PS This is from memory, one of the developers are better qualified to answer this question, if you don't trust my answer, but the generalization is at least correct, AFAICT. When it comes time to using the authorization to compare to domain black/white listing, then the MAIL FROM domain and the EHLO/HELO domain could be used as a query to the lists. So THEN a bad reputation of either the domain in your MAIL FROM or your EHLO/HELO could give you a bad score later down the line in SA or the like. But I don't think anyone is doing that, if for no other reason then because there are no ways of confirming the email is from the domain it claims until SPF is deployed. Terry > > > -- Terry Fielder terry@greatgulfhomes.com Associate Director Software Development and Deployment Great Gulf Homes / Ashton Woods Homes Fax: (416) 441-9085 From owner-ietf-mxcomp@mail.imc.org Thu May 26 14:48:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20722 for ; Thu, 26 May 2005 14:48:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QIS4RK061445; Thu, 26 May 2005 11:28:04 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QIS4sj061444; Thu, 26 May 2005 11:28:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tom.iecc.com (tom.iecc.com [208.31.42.38]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4QIS3mj061436 for ; Thu, 26 May 2005 11:28:03 -0700 (PDT) (envelope-from prvs=johnl/09290505df@iecc.com) Received: (qmail 14285 invoked from network); 26 May 2005 18:28:02 -0000 Received: (ofmipd 208.31.42.47); 26 May 2005 18:27:40 -0000 Date: 26 May 2005 14:28:04 -0400 Message-ID: <20050526142311.O9890@simone.iecc.com> From: "John L" To: "Terry Fielder" Cc: ietf-mxcomp@imc.org Subject: Re: SPF and HELO, was Re: SPF PASS In-Reply-To: <42960F81.3010706@ashtonwoodshomes.com> References: <20050526170838.3089.qmail@xuxa.iecc.com> <42960F81.3010706@ashtonwoodshomes.com> Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >> Yeah. Too bad that among SPF's many flaws is that it completely >> confuses the HELO domain and the MAIL FROM domain > No it does not. It checks each independently. See my previous post to your > question. Could you show me the SPF records I would use to indicate that mta.example,com is valid as an EHLO but not as a bounce address domain while example.com is a valid bounce address domain but not an EHLO. If it'll help, assume they both have an A record of 12.34.56.78. >> (and on a bad day, >> the domains in From:, Sender:, Resent-From:, and Resent-Sender:.) > > SPF never does that, please do not confuse PRA with SPF. In real life, lots of people use SPF records for PRA, and there was a loud debate before coming to a consensus that the alternative of throwing everything away and starting over was unworkable. I sure wish the SPF crowd had a better institutional memory. R's, John From owner-ietf-mxcomp@mail.imc.org Thu May 26 14:48:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20741 for ; Thu, 26 May 2005 14:48:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QIUjQU061671; Thu, 26 May 2005 11:30:45 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QIUjJD061670; Thu, 26 May 2005 11:30:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from io.link-m.de (daemon@io.link-m.de [195.30.85.225]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QIUiwV061662 for ; Thu, 26 May 2005 11:30:45 -0700 (PDT) (envelope-from bulk@mehnle.net) Received: from gray.home.mehnle.net (p549A3223.dip.t-dialin.net [::ffff:84.154.50.35]) (AUTH: PLAIN julian@mehnle.net, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by io.link-m.de with esmtp; Thu, 26 May 2005 20:30:42 +0200 id 00000152.429615D3.00005997 From: Julian Mehnle Reply-To: julian@mehnle.net To: ietf-mxcomp@imc.org Subject: Re: SPF and HELO, was Re: SPF PASS (was: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/") Date: Thu, 26 May 2005 20:30:34 +0200 User-Agent: KMail/1.7.2 References: <20050526170838.3089.qmail@xuxa.iecc.com> In-Reply-To: <20050526170838.3089.qmail@xuxa.iecc.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7449458.DvnOGdUysx"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200505262030.35338.bulk@mehnle.net> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --nextPart7449458.DvnOGdUysx Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable John Levine wrote: > Yeah. Too bad that among SPF's many flaws is that it completely > confuses the HELO domain and the MAIL FROM domain I agree that the combined HELO+MAILFROM semantics somewhat limit the=20 expressiveness of SPF, but as those semantics have been clear since the=20 earliest days of SPFv1, I don't think this is a significant problem. > (and on a bad day, the domains in From:, Sender:, Resent-From:, and > Resent-Sender:.)=20 SPF doesn't do that. Sender-ID does. Complain to Microsoft and the IESG. --nextPart7449458.DvnOGdUysx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBClhXLwL7PKlBZWjsRAuu4AKCXvlrGpup+1MZ0bGkXWrKykv/8aACeI/cN jMzTjQyE6l9PqjVvCyEBGZ0= =uroc -----END PGP SIGNATURE----- --nextPart7449458.DvnOGdUysx-- From owner-ietf-mxcomp@mail.imc.org Thu May 26 14:53:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21003 for ; Thu, 26 May 2005 14:53:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QIb1m2062278; Thu, 26 May 2005 11:37:01 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QIb1Hk062277; Thu, 26 May 2005 11:37:01 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QIaxhZ062271 for ; Thu, 26 May 2005 11:37:00 -0700 (PDT) (envelope-from SRS0=4JPp0DKG=UB=asarian-host.net=admin@asarian-host.net) Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) (authenticated bits=0) by mail.asarian-host.net (8.13.4/8.13.4) with ESMTP id j4QIawd9060310 for ; Thu, 26 May 2005 20:36:58 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: sender IP is authenticated by a trusted mechanism) receiver=asarian-host.net; client-ip=sender IP; envelope-from=; helo=asarian-host; Message-Id: <200505261836.j4QIaw4l060300@asarian-host.net> Date: Thu, 26 May 2005 18:36:58 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: RE: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/" X-Trace: u+q6Kp1aXCgWBPPLKwM4MpLYk6ovi5gI3bQaGPXAWmElW3oogA5NTVrxAh2JNsll/z/RHVY83gSuKuBiBgmfZg== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Auth: Asarian-host PGP signature iQEVAwUAQpYXSjFqW1BleBN9AQFBHAgAkZoSigBQs19pAE/itKkHD9WoFlLbcjxl pnk6dVRot/t2yB7JTIqG+JXALayrVSDVmTS9QowTH6DwxoYgpA8zcwRySE4OJvF8 yG29fb6OmHTjP2mwzLGSExCX52PucvNh400eO6hACRCmkjMXmELp1SymDNNDgNtl IQSgTSnO8Lk2hG48rZaMEeAyNuDIgD4IJ0TN2CT129X51HezH1v/JEjK3Bwc80hU K0sWx37ALBXolJY1XhT5SnZUkDnAWb+GV2YlVr+KB0fqfrW3q7vlMB5NLp1zqLu1 oIaMzDQHntrRfk1aa5n+7CaYSUVmUjkFbx/WGVKEdT/fJd7TUHtJFA== =3IvH Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Richard Clayton > Sent: donderdag 26 mei 2005 18:44 > To: ietf-mxcomp@imc.org > Subject: Re: "If you believe that the SPF concept is > fundamentally flawed, please subscribe at > http://www.imc.org/ietf-mxcomp/" > > In article <200505261315.j4QDFtoB048070@asarian-host.net>, Mark > writes > > >To sum it up: > > > > 1): Spammers causing their registered domains to "pass", > > only identify and>set themselves up to be block-listed. > > so it would be foolish of them to keep on using their domains Ah, but they would not have much of a choice, now, would they? :) Because registering their own domains, to make them SPF "pass", was a stop-gap to begin with, as they could no longer use the more reputable, protected domains. > > 2): Email sent with reputable domains, used without authorization by > > spammers, > > so they can't borrow domains and send the email from their machines > > with you so far :) Yep; that's the idea. > Of course you may feel that if fred@example.com is so dumb as > to install a spam-sending trojan that it serves him right if example.com > gets a really bad reputation. In all fairness, yes. I mean, SPF will help you protect against the misuse of your domain name by unauthorized relays. If you're no longer master of your domain, so to speak, and your own, authorized machines start sending out spam, well, then not even SPF can help you. But if you lost control over your machine, then I'd say you probably have a bigger problem on your hand than worrying about SPF. > However, if I have a need to swap email with > example.com employees how exactly has SPF improved the > situation here ? If your own machines start spewing spam, against your will and control, then your first order of business should be to tell your employees not to chit-chat with others in email until they fixed the flagrant breach of security. :) Seriously, though, here SPF cannot help you, either: in order to exercise control over your domain, you kinda have to be in control of your domain. > Seems to me SPF might have a few advantages relating to > back-scatter but that too much email is being forwarded > for that to work out in the near future. However, > promoting it on the basis that spammers will not change > their behaviour doesn't seem to be justified. Whoever promoted SPF on the basis that spammers will not change should be taken into the backyard and shot. :) SPF counts on spammers to change! Try and look at SPF from a 'selfish' perspective: if you protect your own domain name with SPF, then whatever other domains spammers use, at least it won't be yours. And that 'selfish' point of view is really all a domain owner is interested in: "So what if spammers will go use X instead? At least they're not using Y any more, which is mine. And if that bothers the domain owner of X, he is free to do the same." - Mark System Administrator Asarian-host.org --- "If you were supposed to understand it, we wouldn't call it code." - FedEx From owner-ietf-mxcomp@mail.imc.org Thu May 26 14:54:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21032 for ; Thu, 26 May 2005 14:54:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QIavIm062269; Thu, 26 May 2005 11:36:57 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QIav4h062268; Thu, 26 May 2005 11:36:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from io.link-m.de (daemon@io.link-m.de [195.30.85.225]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QIav99062260 for ; Thu, 26 May 2005 11:36:57 -0700 (PDT) (envelope-from bulk@mehnle.net) Received: from gray.home.mehnle.net (p549A3223.dip.t-dialin.net [::ffff:84.154.50.35]) (AUTH: PLAIN julian@mehnle.net, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by io.link-m.de with esmtp; Thu, 26 May 2005 20:36:55 +0200 id 00000152.42961747.000059D0 From: Julian Mehnle Reply-To: julian@mehnle.net To: ietf-mxcomp@imc.org Subject: Re: SPF PASS (was: "If you believe that the SPF concept is fundam entally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/") Date: Thu, 26 May 2005 20:36:44 +0200 User-Agent: KMail/1.7.2 References: <20050526171042.5259.qmail@xuxa.iecc.com> In-Reply-To: <20050526171042.5259.qmail@xuxa.iecc.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1168019.p7YmM0IR4c"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200505262036.45430.bulk@mehnle.net> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --nextPart1168019.p7YmM0IR4c Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable John Levine wrote: > We could, but since you can't tell whether the list of addresses in > an SPF record is supposed to apply to the EHLO address or the MAIL FROM > address or one of the message header addresses, what's the point? If it starts with "v=3Dspf1", its semantics is defined in draft-schlitt-spf= =2D=20 classic, which, in a long tradition, defines such records to apply both to= =20 the HELO/EHLO and MAIL FROM identites, and no others. > The domain names in my EHLOs is completely disjoint from the set in my > MAIL FROM and mail headers. How is SPF going to handle that? Great! If you are using separate sets of domains for HELO/EHLO and MAIL=20 =46ROM, you can use separate SPF records for each of them. Problem solved. --nextPart1168019.p7YmM0IR4c Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBClhc9wL7PKlBZWjsRAueMAKCTWFVndt9SWTXYvLCIIXpQvXZ7mgCgiGQ6 n1O95lwj/7jFTIvutO3un0M= =6gjW -----END PGP SIGNATURE----- --nextPart1168019.p7YmM0IR4c-- From owner-ietf-mxcomp@mail.imc.org Thu May 26 14:57:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21240 for ; Thu, 26 May 2005 14:57:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QIdeSI062483; Thu, 26 May 2005 11:39:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QIdex7062482; Thu, 26 May 2005 11:39:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QIdctm062473 for ; Thu, 26 May 2005 11:39:39 -0700 (PDT) (envelope-from terry@ashtonwoodshomes.com) Received: from [10.243.102.72] ([216.191.52.74]) (authenticated bits=0) by mail.greatgulfhomes.com (8.12.8/8.12.8) with ESMTP id j4QIeKGk011633; Thu, 26 May 2005 14:40:20 -0400 Message-ID: <4296181A.40806@ashtonwoodshomes.com> Date: Thu, 26 May 2005 14:40:26 -0400 From: Terry Fielder User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John L CC: ietf-mxcomp@imc.org Subject: Re: SPF and HELO, was Re: SPF PASS References: <20050526170838.3089.qmail@xuxa.iecc.com> <42960F81.3010706@ashtonwoodshomes.com> <20050526142311.O9890@simone.iecc.com> In-Reply-To: <20050526142311.O9890@simone.iecc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit John L wrote: >>> Yeah. Too bad that among SPF's many flaws is that it completely >>> confuses the HELO domain and the MAIL FROM domain >> >> No it does not. It checks each independently. See my previous post >> to your question. > > > Could you show me the SPF records I would use to indicate that > mta.example,com is valid as an EHLO but not as a bounce address domain > while example.com is a valid bounce address domain but not an EHLO. If > it'll help, assume they both have an A record of 12.34.56.78. You cannot with SPFv1 (based on your assumption). You missed the point: It doesn't matter, primarily the HELO is only checked if the MAIL FROM fails. A pass from the HELO or MAIL FROM results in SPF PASS status. > >>> (and on a bad day, >>> the domains in From:, Sender:, Resent-From:, and Resent-Sender:.) >> >> >> SPF never does that, please do not confuse PRA with SPF. > > > In real life, lots of people use SPF records for PRA, Name one ISP MSP or ISP. Small time single domain self maintained organizational mail servers don't really count in the volume of things, but just for the hell of it, try naming a few of those. > and there was a > loud debate before coming to a consensus that the alternative of > throwing everything away and starting over was unworkable. I sure wish > the SPF crowd had a better institutional memory. I fail to see how the crowds memory has changed. Currently the SPF council is writing the official "what is SPFv1" so then it can be carried forth to "what should be in the successor version". > > R's, > John > -- Terry Fielder terry@greatgulfhomes.com Associate Director Software Development and Deployment Great Gulf Homes / Ashton Woods Homes Fax: (416) 441-9085 From owner-ietf-mxcomp@mail.imc.org Thu May 26 14:58:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21279 for ; Thu, 26 May 2005 14:58:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QId76h062438; Thu, 26 May 2005 11:39:07 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QId7kW062437; Thu, 26 May 2005 11:39:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QId5wP062429 for ; Thu, 26 May 2005 11:39:06 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DbND1-0004Pp-B5 for ietf-mxcomp@imc.org; Thu, 26 May 2005 20:35:55 +0200 Received: from c-134-89-89.hh.dial.de.ignite.net ([62.134.89.89]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 May 2005 20:35:55 +0200 Received: from nobody by c-134-89-89.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 May 2005 20:35:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: SPF PASS Date: Thu, 26 May 2005 20:27:54 +0200 Organization: Lines: 21 Message-ID: <4296152A.36E5@xyzzy.claranet.de> References: <114DE040D7A6524E9C3B000F47CCD8BD0C450C1A@S2U.LOCAL> <55a5ed639e56e4e706aef879165b476e@hxr.us> <4295EDCF.4020707@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-89-89.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Carl Hutzler wrote: > I wish there was a way to utilize the relatively large number > of SPF records in a technology like CSV. You could try the SIQ-idea: input IP and FQDN, output PASS, FAIL, or DUNNO. The SIQ-server checks CSV and if n/a SPF to create its (IP, FQDN, result, TTL) HELO-tuples. If the SIQ-server is forced to use SPF (no CSV) to create its records it could ignore all policies with the vague qualifiers ? or ~, and it could also ignore all "expensive" SPF policies, anything with mx, ptr, include could be defined as "forget it, too expensive for a simple HELO test". So you only look at +/-a +/-ip4, +/-ip6, +/-all. I'm not sure about "mx" and "exists", a dedicated SIQ-server could have enough time to evaluate these mechanisms. Bye, Frank P.S., you better add MTAMARK before CSV before restricted SPF From owner-ietf-mxcomp@mail.imc.org Thu May 26 15:02:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21550 for ; Thu, 26 May 2005 15:02:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QEmhih017648; Thu, 26 May 2005 07:48:43 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QEmhjc017647; Thu, 26 May 2005 07:48:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from imo-m21.mx.aol.com (imo-m21.mx.aol.com [64.12.137.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QEmg7W017629 for ; Thu, 26 May 2005 07:48:42 -0700 (PDT) (envelope-from CDHutzler@aol.com) Received: from CDHutzler@aol.com by imo-m21.mx.aol.com (mail_out_v38_r1.7.) id g.ea.6a182ee5 (15875); Thu, 26 May 2005 10:47:58 -0400 (EDT) Received: from [10.180.64.10] ([10.180.64.10]) by air-id07.mx.aol.com (v106.2) with ESMTP id MAILINID72-3e034295e19e3e3; Thu, 26 May 2005 10:47:58 -0400 Message-ID: <4295E19E.2040900@aol.com> Date: Thu, 26 May 2005 10:47:58 -0400 From: Carl Hutzler User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: admin@asarian-host.net CC: ietf-mxcomp@imc.org Subject: Re: "If you believe that the SPF concept is fundamentally flawed,please subscribe at http://www.imc.org/ietf-mxcomp/" References: <200505261402.j4QE25pq049874@asarian-host.net> In-Reply-To: <200505261402.j4QE25pq049874@asarian-host.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 10.180.64.10 X-Mailer: Unknown (No Version) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit admin@asarian-host.net wrote: > > >>-----Original Message----- >>From: Arnt Gulbrandsen [mailto:arnt@gulbrandsen.priv.no] >>Sent: donderdag 26 mei 2005 15:41 >>To: ietf-mxcomp@imc.org >>Cc: Mark >>Subject: Re: "If you believe that the SPF concept is >>fundamentally flawed,please subscribe at >>http://www.imc.org/ietf-mxcomp/" >> >> >> >>Mark writes: >> >> > > > >>>SPF is inter-MTA based, and requires no changes to email clients >>>whatso-frickin-ever. >>> >>> >>The first time I looked at SPF was because I wanted to ensure that an >>email client was okay. Specifically, I wanted to check outgoing mail >>from a roadwarrior machine, and warn the user before sending any mail >>that would likely fail. >> >>That job wasn't so easy. Not so easy. >> >> > >It is up to the ISP/MTA how to deal with their roaming users. Typically, >SMTP AUTH / DRAC is used (that has nothing to do with SPF even, but >everything with your ISP not being an open relay and still allowing its >customers roaming access). So, if you send mail, from the road, through >the relay you authorized, then that relay should SPF "pass" you (provided >you use the correct domain name, of course). > >Sending through someone else's, unauthorized relay may, indeed, present a >problem on the receiving end if they check SPF (and thus would reject your >mail). But that is the whole point: either we allow everyone to use every >domain name through every relay (they have access to), or we specify >authorized relays. If we do the latter, then naturally doing the former >will no longer work. I believe that is a good thing. > >It will take some mentality adjusting, though; like way back when, when >people said: "I used to be able to send through every SMTP server I >wanted; and now, dangit, I can only use the ones I have been given >access to." That change, too, was a good thing. > > BTW, this issue of allowing someone to send through "someone else's relay" is a problem for ALL email authentication approaches except perhaps CSV and BATV. DomainKeys, SPF, IIM, and SID all have an issue until we can get MUAs to sign with DK/IIM. -Carl -- Carl Hutzler Director, Host Mail Development America Online cdhutzler@aol.com 703.265.5521 work 703.915.6862 cell From owner-ietf-mxcomp@mail.imc.org Thu May 26 15:03:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21637 for ; Thu, 26 May 2005 15:03:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QIgVSJ062735; Thu, 26 May 2005 11:42:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QIgV2R062733; Thu, 26 May 2005 11:42:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QIgUk2062722 for ; Thu, 26 May 2005 11:42:30 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j4QIg69l003035; Thu, 26 May 2005 11:42:06 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j4QIg63I003032; Thu, 26 May 2005 11:42:06 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Thu, 26 May 2005 11:42:06 -0700 (PDT) From: "william(at)elan.net" To: Terry Fielder cc: John Levine , ietf-mxcomp@imc.org Subject: Re: SPF PASS In-Reply-To: <42960E85.7070503@ashtonwoodshomes.com> Message-ID: References: <20050526171042.5259.qmail@xuxa.iecc.com> <42960E85.7070503@ashtonwoodshomes.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 26 May 2005, Terry Fielder wrote: >> The domain names in my EHLOs is completely disjoint from the set in my >> MAIL FROM and mail headers. How is SPF going to handle that? >> > I believe you will find that the EHLO/HELO is only checked if the MAIL FROM > fails. Why? Doing EHLO check is useful no matter if MAILFROM fails or passes! And it does not make any sense to delay it until MAILFROM when EHLO is the first identity parameter email server receives and this identity that has very few failure cases with SPF (unlike MAILFROM) Also note that MAILFROM identity corresponds to original recipient (unless every forwarder starts using SRS and you change its semantics, but that is unlikely) where as EHLO name corresponds to the mail system. As John proper said, they are disjoint and should not be mixed. > I think I have heard of other implementations where: > If the EHLO fails, you check the MAIL FROM, and if that passes then it gets > an SPF pass. Unless I'm mistaken SPF pass is specific per scope/identity checked and there is no overall SPF pass. > Either way, it doesn't matter if your EHLO fails (it does on many, maybe even > MOST systems), because as long as your MAIL FROM is SPF PASS, then your mails > SPF response on the whole is a PASS, and is not negatively affected. > > PS This is from memory, one of the developers are better qualified to answer > this question, if you don't trust my answer, but the generalization is at > least correct, AFAICT. > > When it comes time to using the authorization to compare to domain > black/white listing, then the MAIL FROM domain and the EHLO/HELO domain could > be used as a query to the lists. You should not query different identities on the same reputation service, I believe that is a possibility for unpredictable and incorrect results and reputation systems must be setup for each specific identity in question. ---- BTW, for those who do not participate at spf-discuss and don't know - I'm writing paper on email identities and how they are used in path and cryptographic authentication methods (i.e LMAP and MASS) for anti-spoofing protection. This is very much on the topic of what has been discussed here and on ietf-smtp about good and bad points of each proposal. You can find the latest public draft at: http://www.elan.net/~william/emailsecurity/path_and_cryptographic_authentication-draft-limited-07.htm Comments on the content, especially if I got anything wrong are appreciated. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Thu May 26 15:05:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21926 for ; Thu, 26 May 2005 15:05:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QIkOOV063028; Thu, 26 May 2005 11:46:24 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QIkOuQ063027; Thu, 26 May 2005 11:46:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from io.link-m.de (daemon@io.link-m.de [195.30.85.225]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QIkNY6063013 for ; Thu, 26 May 2005 11:46:23 -0700 (PDT) (envelope-from bulk@mehnle.net) Received: from gray.home.mehnle.net (p549A3223.dip.t-dialin.net [::ffff:84.154.50.35]) (AUTH: PLAIN julian@mehnle.net, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by io.link-m.de with esmtp; Thu, 26 May 2005 20:46:21 +0200 id 00000152.4296197E.00005A18 From: Julian Mehnle Reply-To: julian@mehnle.net To: MARID Subject: Re: "If you believe that the SPF concept is fundamentally flawed,please subscribe at http://www.imc.org/ietf-mxcomp/" Date: Thu, 26 May 2005 20:46:11 +0200 User-Agent: KMail/1.7.2 References: <200505261402.j4QE25pq049874@asarian-host.net> <4295E19E.2040900@aol.com> In-Reply-To: <4295E19E.2040900@aol.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2295817.PVzkAmzJlm"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200505262046.11837.bulk@mehnle.net> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --nextPart2295817.PVzkAmzJlm Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Carl Hutzler wrote: > BTW, this issue of allowing someone to send through "someone else's > relay" is a problem for ALL email authentication approaches except > perhaps CSV and BATV. DomainKeys, SPF, IIM, and SID all have an issue > until we can get MUAs to sign with DK/IIM. If end-users (MUAs) are to use shared private keys (e.g. for a common=20 sender domain), the confidentiality of the private keys is at risk. If end-users are to use user-specific private keys, they could very well=20 use PGP or S/MIME right away. IMO this is the direction things need to be= =20 going. --nextPart2295817.PVzkAmzJlm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBClhlzwL7PKlBZWjsRAtkhAKC2xrm2KksvloDAlSdzXhC2wVshCgCghJui 9cyYPWdNilUOTW6c3ls4gb4= =+CDK -----END PGP SIGNATURE----- --nextPart2295817.PVzkAmzJlm-- From owner-ietf-mxcomp@mail.imc.org Thu May 26 15:06:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22011 for ; Thu, 26 May 2005 15:06:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QInQf8063285; Thu, 26 May 2005 11:49:26 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QInQqC063284; Thu, 26 May 2005 11:49:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QInPIU063269 for ; Thu, 26 May 2005 11:49:25 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DbNN3-0005Wh-VU for ietf-mxcomp@imc.org; Thu, 26 May 2005 20:46:17 +0200 Received: from c-134-89-89.hh.dial.de.ignite.net ([62.134.89.89]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 May 2005 20:46:17 +0200 Received: from nobody by c-134-89-89.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 May 2005 20:46:17 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: SPF PASS Date: Thu, 26 May 2005 20:46:33 +0200 Organization: Lines: 15 Message-ID: <42961989.5878@xyzzy.claranet.de> References: <20050526171042.5259.qmail@xuxa.iecc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-89-89.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit John Levine wrote: > The domain names in my EHLOs is completely disjoint from the > set in my MAIL FROM and mail headers. How is SPF going to > handle that? Different FQDNs have different policies (for a HELO FQDN it's generally possible to arrange things so that it's different from MAIL FROM FQDNs) That's exactly what Carl wants, use a _simple_ policy for the HELO FQDN. Or convince him to test CSV, and use CSV. Or do both, then he can do whatever pleases him. For a HELO FQDN "v=spf1 a -all" should be generally good enough. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Thu May 26 15:06:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22092 for ; Thu, 26 May 2005 15:06:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QIodUW063418; Thu, 26 May 2005 11:50:39 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QIodoa063417; Thu, 26 May 2005 11:50:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QIocw7063383 for ; Thu, 26 May 2005 11:50:38 -0700 (PDT) (envelope-from terry@ashtonwoodshomes.com) Received: from [10.243.102.72] ([216.191.52.74]) (authenticated bits=0) by mail.greatgulfhomes.com (8.12.8/8.12.8) with ESMTP id j4QIpLGk012358; Thu, 26 May 2005 14:51:21 -0400 Message-ID: <42961AAF.5070005@ashtonwoodshomes.com> Date: Thu, 26 May 2005 14:51:27 -0400 From: Terry Fielder User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "william(at)elan.net" CC: John Levine , ietf-mxcomp@imc.org Subject: Re: SPF PASS References: <20050526171042.5259.qmail@xuxa.iecc.com> <42960E85.7070503@ashtonwoodshomes.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit william(at)elan.net wrote: > > On Thu, 26 May 2005, Terry Fielder wrote: > >>> The domain names in my EHLOs is completely disjoint from the set in my >>> MAIL FROM and mail headers. How is SPF going to handle that? >>> >> I believe you will find that the EHLO/HELO is only checked if the MAIL >> FROM fails. > > > Why? Doing EHLO check is useful no matter if MAILFROM fails or passes! > And it does not make any sense to delay it until MAILFROM when EHLO is > the first identity parameter email server receives and this identity > that has very few failure cases with SPF (unlike MAILFROM) Right, I fell into the the JL trap of thinking that the two domains had to be the same and yet represent something different. But if its a relay server, the HELO *will* be different and consequently *will* use a different SPF record (if one exists). > > Also note that MAILFROM identity corresponds to original recipient > (unless every forwarder starts using SRS and you change its semantics, > but that is unlikely) where as EHLO name corresponds to the mail system. > As John proper said, they are disjoint and should not be mixed. > >> I think I have heard of other implementations where: >> If the EHLO fails, you check the MAIL FROM, and if that passes then it >> gets an SPF pass. > > > Unless I'm mistaken SPF pass is specific per scope/identity checked and > there is no overall SPF pass. That was not my understanding, but I accept being corrected if that's the case. > >> Either way, it doesn't matter if your EHLO fails (it does on many, >> maybe even MOST systems), because as long as your MAIL FROM is SPF >> PASS, then your mails SPF response on the whole is a PASS, and is not >> negatively affected. >> >> PS This is from memory, one of the developers are better qualified to >> answer this question, if you don't trust my answer, but the >> generalization is at least correct, AFAICT. >> >> When it comes time to using the authorization to compare to domain >> black/white listing, then the MAIL FROM domain and the EHLO/HELO >> domain could be used as a query to the lists. > > > You should not query different identities on the same reputation service, > I believe that is a possibility for unpredictable and incorrect results > and reputation systems must be setup for each specific identity in > question. I disagree, a domain may authorize RELAY.com to relay his email. But if RELAY.com is notoroious for sending spam (from his other customers he relays for), then when I check the HELO name I may want to reject the mail from RELAY.com because of his bad spamming reputation even if the "MAIL FROM" domain is SPF PASS for said relay. Consider the case when RELAY.com is actually SPAMMER.com, and once SPAMMER.com is black listed you want to keep blocking mail from him even if he registers other throwaway domains to pretend his server SPAMMER.com is relaying for. A thumbs up on the reputation of THROWAWAY.com may want to be ignored if a thumbs down occurs for the MTA SPAMMER.com > > ---- > > BTW, for those who do not participate at spf-discuss and don't know - > I'm writing paper on email identities and how they are used in path and > cryptographic authentication methods (i.e LMAP and MASS) for anti-spoofing > protection. This is very much on the topic of what has been discussed > here and on ietf-smtp about good and bad points of each proposal. > > You can find the latest public draft at: > > http://www.elan.net/~william/emailsecurity/path_and_cryptographic_authentication-draft-limited-07.htm > > > Comments on the content, especially if I got anything wrong are > appreciated. > -- Terry Fielder terry@greatgulfhomes.com Associate Director Software Development and Deployment Great Gulf Homes / Ashton Woods Homes Fax: (416) 441-9085 From owner-ietf-mxcomp@mail.imc.org Thu May 26 15:07:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22247 for ; Thu, 26 May 2005 15:07:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QIuEMq068418; Thu, 26 May 2005 11:56:14 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QIuEMj068417; Thu, 26 May 2005 11:56:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tom.iecc.com (tom.iecc.com [208.31.42.38]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4QIuCQQ068402 for ; Thu, 26 May 2005 11:56:13 -0700 (PDT) (envelope-from prvs=johnl/09290505df@iecc.com) Received: (qmail 22585 invoked from network); 26 May 2005 18:56:12 -0000 Received: (ofmipd 208.31.42.47); 26 May 2005 18:55:50 -0000 Date: 26 May 2005 14:56:13 -0400 Message-ID: <20050526145228.N10044@simone.iecc.com> From: "John L" To: "Terry Fielder" Cc: ietf-mxcomp@imc.org Subject: Re: SPF and HELO, was Re: SPF PASS In-Reply-To: <4296181A.40806@ashtonwoodshomes.com> References: <20050526170838.3089.qmail@xuxa.iecc.com> <42960F81.3010706@ashtonwoodshomes.com> <20050526142311.O9890@simone.iecc.com> <4296181A.40806@ashtonwoodshomes.com> Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >> Could you show me the SPF records I would use to indicate that >> mta.example.com is valid as an EHLO but not as a bounce address domain >> while example.com is a valid bounce address domain but not an EHLO. If >> it'll help, assume they both have an A record of 12.34.56.78. > > You cannot with SPFv1 (based on your assumption). You missed the point: It > doesn't matter, primarily the HELO is only checked if the MAIL FROM fails. > > A pass from the HELO or MAIL FROM results in SPF PASS status. My point, which I would have thought was obvious, is that SPF provides no way to say that EHLO example.com or MAIL FROM: are invalid. In practice, I see quite a lot of forged mail like that, and SPF's inability to deal with it is a significant problem. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor "I dropped the toothpaste", said Tom, crestfallenly. From owner-ietf-mxcomp@mail.imc.org Thu May 26 15:14:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22956 for ; Thu, 26 May 2005 15:14:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QIuPM0068440; Thu, 26 May 2005 11:56:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QIuPNm068439; Thu, 26 May 2005 11:56:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.asarian-host.net (mail.asarian-host.net [194.109.160.70]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QIuO3K068432 for ; Thu, 26 May 2005 11:56:24 -0700 (PDT) (envelope-from SRS0=4JPp0DKG=UB=asarian-host.net=admin@asarian-host.net) Received: from anonymizer.asarian-host.net (localhost [127.0.0.1]) (authenticated bits=0) by mail.asarian-host.net (8.13.4/8.13.4) with ESMTP id j4QIuNOx060872 for ; Thu, 26 May 2005 20:56:23 +0200 (CEST) (envelope-from admin@asarian-host.net) From: Mark Received-SPF: pass (asarian-host.net: sender IP is authenticated by a trusted mechanism) receiver=asarian-host.net; client-ip=sender IP; envelope-from=; helo=asarian-host; Message-Id: <200505261856.j4QIuN9f060862@asarian-host.net> Date: Thu, 26 May 2005 18:56:23 GMT X-Authenticated-Sender: admin@asarian-host.net Subject: RE: SPF PASS (was: "If you believe that the SPF concept is fundam entally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/") X-Trace: QryM3mxx7t8mMqsMs6r++/CkBzM9GDc+2BWk5cqI7xjG8EYOkMxLoxAPHeLEnojg3yyR1mh9heMqjCACN386tw== X-Complaints-To: abuse@asarian-host.net X-Abuse-Info: Please be sure to forward a copy of ALL headers, otherwise we are unable to process your complaint Organization: Asarian-host To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <20050526171042.5259.qmail@xuxa.iecc.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-Auth: Asarian-host PGP signature iQEVAwUAQpYb1zFqW1BleBN9AQEy+gf+IeLakHNnDKDUYIVgO/iRMSUI+xG2wn3H yFQuBAVD5hyRg0uliF7g6DXuS1GgG2+LW9O2RGa9vs9s/2H4xFfPzHgY3YtnkbOt Wtu07muM6WaFrr0RBzg5utE1KRiVNwTOmKda8++jK6tL18n78ZHlnMejUlmaP1zD holpWy3x5GHUBLAYn3+pgC0wIb/2TNuAfA/Ptm1rjWERZw+ODZuwv08A76AMsklQ In4eNMpZslfMz5PROecodcpYdTufl79wwX6n4fHyHgZIuTMD4/BVuaOs3JKJyobo CsAWEQ1dCNJVuMHqaZYdbR9qgLEBF41yg7u2pWMDYE5mBGk5b8Po4g== =Y/IR Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-mxcomp@mail.imc.org > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of John Levine > Sent: donderdag 26 mei 2005 19:12 > To: ietf-mxcomp@imc.org > Cc: william@elan.net > Subject: Re: SPF PASS (was: "If you believe that the SPF > concept is fundam entally flawed, please subscribe at > http://www.imc.org/ietf-mxcomp/") > > > > The domain names in my EHLOs is completely disjoint from the set in my > MAIL FROM and mail headers. How is SPF going to handle that? Typically, HELO/EHLO is only used in the special case of MAIL FROM: <>, so to have the SPF client check against postmaster@HELO. Since there is no MAIL FROM identity to protect in case of an empty envelope-from, it would suffice to just publish this simple SPF record (BIND style) for your completely disjoint HELO/EHLO name: completelydisjoint.mydomain.com. TXT "v=spf1 a -all" That will ensure, that in the case of a DSN, your own mailer is always authorized (and no one else!). That easy. - Mark System Administrator Asarian-host.org --- "If you were supposed to understand it, we wouldn't call it code." - FedEx From owner-ietf-mxcomp@mail.imc.org Thu May 26 15:20:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23650 for ; Thu, 26 May 2005 15:20:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QJ2Jtr068865; Thu, 26 May 2005 12:02:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QJ2JZC068864; Thu, 26 May 2005 12:02:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QJ2Iwh068854 for ; Thu, 26 May 2005 12:02:18 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DbNZV-00079T-T5 for ietf-mxcomp@imc.org; Thu, 26 May 2005 20:59:09 +0200 Received: from c-134-89-89.hh.dial.de.ignite.net ([62.134.89.89]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 May 2005 20:59:09 +0200 Received: from nobody by c-134-89-89.hh.dial.de.ignite.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 May 2005 20:59:09 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: SPF and HELO Date: Thu, 26 May 2005 20:59:49 +0200 Organization: Lines: 14 Message-ID: <42961CA5.4516@xyzzy.claranet.de> References: <114DE040D7A6524E9C3B000F47CCD8BD0C450C1A@S2U.LOCAL> <55a5ed639e56e4e706aef879165b476e@hxr.us> <4295EDCF.4020707@aol.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: c-134-89-89.hh.dial.de.ignite.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit william(at)elan.net wrote: > need I mention USEFOR perhaps... For his sins (3710, MARID) Harald was now condemned to be a co-chair, he has already found the first trap and pitfall ;-) > Oh well, enough of history... Lets hope we can salvage at > least some of what we had worked for in the future even > if it will not happen quickly. ACK. Delete one erroneous SHOULD in senderid-core and move on, I like this SIQ idea. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Thu May 26 15:21:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23754 for ; Thu, 26 May 2005 15:21:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QItFDq067718; Thu, 26 May 2005 11:55:15 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QItFKs067717; Thu, 26 May 2005 11:55:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from anchor-post-36.mail.demon.net (anchor-post-36.mail.demon.net [194.217.242.86]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QItEdl067686 for ; Thu, 26 May 2005 11:55:14 -0700 (PDT) (envelope-from richard@highwayman.com) Received: from gti.noc.demon.net ([195.11.55.101] helo=happyday.al.cl.cam.ac.uk) by anchor-post-36.mail.demon.net with esmtp (Exim 4.42) id 1DbNVg-0000Os-MH for ietf-mxcomp@imc.org; Thu, 26 May 2005 18:55:13 +0000 Message-ID: Date: Thu, 26 May 2005 19:53:32 +0100 To: ietf-mxcomp@imc.org From: Richard Clayton Subject: Re: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/" References: <200505260302.49515.bulk@mehnle.net> <200505261315.j4QDFtoB048070@asarian-host.net> In-Reply-To: MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.02 M Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In article , wayne writes > >In Richard Clayton >writes: > >> Hence, since they still want to spam, they will start sending email with >> borrowed domains from borrowed machines... they are already doing the >> latter, they don't do the former because there's currently no need. SPF >> would, if adopted, provide the evolutionary pressure for them to do so. >> >> Of course you may feel that if fred@example.com is so dumb as to install >> a spam-sending trojan that it serves him right if example.com gets a >> really bad reputation. However, if I have a need to swap email with >> example.com employees how exactly has SPF improved the situation here ? > >example.com can quickly update their SPF record to remove the >offending IP address from their approved list. fair enough -- but this is reactive and the reputation service will have been complained to at the same time, possibly well before, example.com learnt of the problem. The reputation of example.com (which apparently SPF is going to allow me to judge) will still suffer. or are you expecting the reputation not to be for example.com but for each individual part of it... if so then I'm still unclear what SPF is bringing to the party here. now consider where example.com is a large company (or an ISP) running a small number of mail servers then (a) the action is NOT going to be to change the SPF record but to revoke an authorisation and (b) it's even more opaque as to how the reputation service can reflect that this has been done or quite what SPF has contributed once again, I don't mind SPF being promoted for what it will do, but when it is argued that other things will flow from that then the justification really doesn't seem to stand up. I repeat my advice from another place to give up proselytising how SPF will make a better world and just concentrate on a comprehensible, interworkable standard that doesn't break anything else. If it then turns out to have magical powers and cures cancer and stuff then that's peachy. But its unnecessary to promote that up front. - -- richard richard.clayton @ h i g h w a y m a n . com "Assembly of Japanese bicycle require great peace of mind" quoted in ZAMM -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBQpYbLJoAxkTY1oPiEQJ2xQCgoA/MSyIgMRnBKeVsyscCJuFW4vgAn0ag WmLALimrRXuZvrDwyiqLmP8i =C5i1 -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Thu May 26 15:22:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23904 for ; Thu, 26 May 2005 15:22:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QJ5siT069168; Thu, 26 May 2005 12:05:54 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QJ5sVh069167; Thu, 26 May 2005 12:05:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QJ5pJM069157 for ; Thu, 26 May 2005 12:05:52 -0700 (PDT) (envelope-from terry@ashtonwoodshomes.com) Received: from [10.243.102.72] ([216.191.52.74]) (authenticated bits=0) by mail.greatgulfhomes.com (8.12.8/8.12.8) with ESMTP id j4QJ6MGk013512; Thu, 26 May 2005 15:06:23 -0400 Message-ID: <42961E34.3060202@ashtonwoodshomes.com> Date: Thu, 26 May 2005 15:06:28 -0400 From: Terry Fielder User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Clayton CC: ietf-mxcomp@imc.org Subject: Re: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/" References: <200505260302.49515.bulk@mehnle.net> <200505261315.j4QDFtoB048070@asarian-host.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Richard Clayton wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > In article , wayne > writes > > >>In Richard Clayton >>writes: >> >> >>>Hence, since they still want to spam, they will start sending email with >>>borrowed domains from borrowed machines... they are already doing the >>>latter, they don't do the former because there's currently no need. SPF >>>would, if adopted, provide the evolutionary pressure for them to do so. >>> >>>Of course you may feel that if fred@example.com is so dumb as to install >>>a spam-sending trojan that it serves him right if example.com gets a >>>really bad reputation. However, if I have a need to swap email with >>>example.com employees how exactly has SPF improved the situation here ? >> >>example.com can quickly update their SPF record to remove the >>offending IP address from their approved list. > > > fair enough -- but this is reactive and the reputation service will have > been complained to at the same time, possibly well before, example.com > learnt of the problem. The reputation of example.com (which apparently > SPF is going to allow me to judge) will still suffer. > > or are you expecting the reputation not to be for example.com but for > each individual part of it... if so then I'm still unclear what SPF is > bringing to the party here. > > now consider where example.com is a large company (or an ISP) running a > small number of mail servers then (a) the action is NOT going to be to > change the SPF record but to revoke an authorisation and (b) it's even > more opaque as to how the reputation service can reflect that this has > been done or quite what SPF has contributed > > > once again, I don't mind SPF being promoted for what it will do, but > when it is argued that other things will flow from that then the > justification really doesn't seem to stand up. > > I repeat my advice from another place to give up proselytising how SPF > will make a better world and just concentrate on a comprehensible, > interworkable standard that doesn't break anything else. If it then > turns out to have magical powers and cures cancer and stuff then that's > peachy. But its unnecessary to promote that up front. Please point me to this "comprehensible, interworkable standard that doesn't break anything else. " (Isn't that the FUSSP?) Meanwhile, I am betting on SPF. Terry > > - -- > richard richard.clayton @ h i g h w a y m a n . com > > "Assembly of Japanese bicycle require great peace of mind" quoted in ZAMM > > -----BEGIN PGP SIGNATURE----- > Version: PGPsdk version 1.7.1 > > iQA/AwUBQpYbLJoAxkTY1oPiEQJ2xQCgoA/MSyIgMRnBKeVsyscCJuFW4vgAn0ag > WmLALimrRXuZvrDwyiqLmP8i > =C5i1 > -----END PGP SIGNATURE----- > -- Terry Fielder terry@greatgulfhomes.com Associate Director Software Development and Deployment Great Gulf Homes / Ashton Woods Homes Fax: (416) 441-9085 From owner-ietf-mxcomp@mail.imc.org Thu May 26 15:36:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25138 for ; Thu, 26 May 2005 15:36:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QJCnOu069776; Thu, 26 May 2005 12:12:50 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QJCnMo069775; Thu, 26 May 2005 12:12:49 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QJCm4n069769 for ; Thu, 26 May 2005 12:12:49 -0700 (PDT) (envelope-from terry@ashtonwoodshomes.com) Received: from [10.243.102.72] ([216.191.52.74]) (authenticated bits=0) by mail.greatgulfhomes.com (8.12.8/8.12.8) with ESMTP id j4QJDXGk013814 for ; Thu, 26 May 2005 15:13:33 -0400 Message-ID: <42961FE3.2060303@ashtonwoodshomes.com> Date: Thu, 26 May 2005 15:13:39 -0400 From: Terry Fielder User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MARID WG Subject: Re: SPF and HELO, was Re: SPF PASS References: <20050526170838.3089.qmail@xuxa.iecc.com> <42960F81.3010706@ashtonwoodshomes.com> <20050526142311.O9890@simone.iecc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit wayne wrote: > In <20050526142311.O9890@simone.iecc.com> "John L" writes: > > >>>>Yeah. Too bad that among SPF's many flaws is that it completely >>>>confuses the HELO domain and the MAIL FROM domain >>> >>>No it does not. It checks each independently. See my previous post >>>to your question. >> >>Could you show me the SPF records I would use to indicate that >>mta.example,com is valid as an EHLO but not as a bounce address domain >>while example.com is a valid bounce address domain but not an EHLO. >>If it'll help, assume they both have an A record of 12.34.56.78. > > > I'll start off by not answering your quesiton. ;-) > > Personally, I would recommend just publishing these SPF records: > > example.com TXT "v=spf a -all" > mta.example.com TXT "v=spf a -all" > > If you trust the host 12.34.56.78 enough to authorize it to use both > the example.com and mta.example.com domain names, why wouldn't you > trust it enough to use them in the right context? > > > Ok, now I'll actually answer your question: > > example.com TXT "v=spf1 redirect=%{i}._spf.%{d}" > postmaster._spf.example.com TXT "v=spf1 -all" > *._spf.example.com TXT "v=spf1 a -all" > > > > mta.example.com TXT "v=spf1 redirect=%{i}._spf.%{d}" > postmaster._spf.mta.example.com TXT "v=spf1 a -all" > *._spf.mta.example.com TXT "v=spf1 -all" > > > ugly as sin, and it means that you can't send email using the > postmaster local part, but other wise it works and is well defined > back to Dec 2003 (or earlier). > I stand corrected, it can be done with SPFv1, hats off to Wayne (and I am going to keep this one for myself to use :) BTW Ugly as sin is irrelevant, once setup only computers need to read it, and it can be as ugly and cryptic as necessary, as long as *it works*. Terry > > -wayne > -- Terry Fielder terry@greatgulfhomes.com Associate Director Software Development and Deployment Great Gulf Homes / Ashton Woods Homes Fax: (416) 441-9085 From owner-ietf-mxcomp@mail.imc.org Thu May 26 15:46:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26944 for ; Thu, 26 May 2005 15:46:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QJPYPY071167; Thu, 26 May 2005 12:25:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QJPYAG071166; Thu, 26 May 2005 12:25:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from io.link-m.de (daemon@io.link-m.de [195.30.85.225]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QJPXh2071160 for ; Thu, 26 May 2005 12:25:34 -0700 (PDT) (envelope-from bulk@mehnle.net) Received: from gray.home.mehnle.net (p549A3223.dip.t-dialin.net [::ffff:84.154.50.35]) (AUTH: PLAIN julian@mehnle.net, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by io.link-m.de with esmtp; Thu, 26 May 2005 21:19:31 +0200 id 00000152.42962143.00005B8E From: Julian Mehnle Reply-To: julian@mehnle.net To: MARID Subject: Re: SPF and HELO Date: Thu, 26 May 2005 21:19:22 +0200 User-Agent: KMail/1.7.2 References: <20050526170838.3089.qmail@xuxa.iecc.com> <42960F81.3010706@ashtonwoodshomes.com> <20050526142311.O9890@simone.iecc.com> In-Reply-To: <20050526142311.O9890@simone.iecc.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5011484.Yr8uUE9z5A"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200505262119.22543.bulk@mehnle.net> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --nextPart5011484.Yr8uUE9z5A Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable John L wrote: > Could you show me the SPF records I would use to indicate that > mta.example,com is valid as an EHLO but not as a bounce address domain > while example.com is a valid bounce address domain but not an EHLO. You can't. The expressiveness of SPFv1 is limited in this regard. However, SPF still effectively prevents forgery of both the "mta.example.=20 com" and "example.com" identities, because no MTAs except those authorized= =20 by your SPF record(s) can use them, and those MTAs authorized by you=20 should be under your control. --nextPart5011484.Yr8uUE9z5A Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBCliE6wL7PKlBZWjsRAt0VAKDkv3YRXvPVuP/gWcdwrTDkt0CnUACgj1rV UWvoUmv+DnA9vkLFnAVniOs= =xFKS -----END PGP SIGNATURE----- --nextPart5011484.Yr8uUE9z5A-- From owner-ietf-mxcomp@mail.imc.org Thu May 26 15:56:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29627 for ; Thu, 26 May 2005 15:56:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QJVeb8071647; Thu, 26 May 2005 12:31:40 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QJVeZT071646; Thu, 26 May 2005 12:31:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from io.link-m.de (daemon@io.link-m.de [195.30.85.225]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QJVdTm071638 for ; Thu, 26 May 2005 12:31:39 -0700 (PDT) (envelope-from bulk@mehnle.net) Received: from gray.home.mehnle.net (p549A3223.dip.t-dialin.net [::ffff:84.154.50.35]) (AUTH: PLAIN julian@mehnle.net, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by io.link-m.de with esmtp; Thu, 26 May 2005 21:31:38 +0200 id 00000152.4296241A.00005C09 From: Julian Mehnle Reply-To: julian@mehnle.net To: MARID Subject: HELO and MAIL FROM are separate identities; reputation on a per-domain basis instead of per-IP (was: SPF PASS) Date: Thu, 26 May 2005 21:31:27 +0200 User-Agent: KMail/1.7.2 References: <20050526171042.5259.qmail@xuxa.iecc.com> <42961AAF.5070005@ashtonwoodshomes.com> In-Reply-To: <42961AAF.5070005@ashtonwoodshomes.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart62065014.AkxHPbzCNv"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200505262131.28018.bulk@mehnle.net> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --nextPart62065014.AkxHPbzCNv Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Terry Fielder wrote: > William Leibzon wrote: > > You should not query different identities on the same reputation > > service, I believe that is a possibility for unpredictable and > > incorrect results and reputation systems must be setup for each > > specific identity in question. William is right. You should not confuse "example.com-the-HELO-domain"=20 with "example.com-the-MAILFROM-domain". You should not query "mailsenders.reputation-provider.com" for HELO=20 identities or "mtas.reputation-provider.com" for MAIL FROM identities. > I disagree, a domain may authorize RELAY.com to relay his email. But if > RELAY.com is notoroious for sending spam (from his other customers he > relays for), then when I check the HELO name I may want to reject the > mail from RELAY.com because of his bad spamming reputation even if the > "MAIL FROM" domain is SPF PASS for said relay. Well, this scenario is actually one of the strengths of SPF (and other=20 sender domain authentication methods). Even if relay.com sends a lot of=20 spam, if you _do_ trust them to prevent cross-user forgery[1], you may be=20 able to still successfully get your own legitimate mail through, because=20 receivers don't necessarily have to block on the relay.com MTA IP address=20 any more, but can assess reputation on a per-domain basis instead. References: 1. =20 http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-01.html#cr= oss-user-forgery --nextPart62065014.AkxHPbzCNv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBCliQPwL7PKlBZWjsRAmomAKCVrVeg8jKPkcsujdfFyRg9Zfe1kwCgpWC4 WxORm+CCvVN0w65gnnlSel4= =/AXV -----END PGP SIGNATURE----- --nextPart62065014.AkxHPbzCNv-- From owner-ietf-mxcomp@mail.imc.org Thu May 26 16:05:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03183 for ; Thu, 26 May 2005 16:05:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QJhZpW072553; Thu, 26 May 2005 12:43:35 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QJhZlb072552; Thu, 26 May 2005 12:43:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QJhYfk072546 for ; Thu, 26 May 2005 12:43:34 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DbOCn-00044e-09 for ietf-mxcomp@imc.org; Thu, 26 May 2005 21:39:45 +0200 Received: from du-001-212.access.de.clara.net ([212.82.227.212]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 May 2005 21:39:44 +0200 Received: from nobody by du-001-212.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 May 2005 21:39:44 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: SPF PASS Date: Thu, 26 May 2005 21:33:34 +0200 Organization: Lines: 29 Message-ID: <4296248E.10D2@xyzzy.claranet.de> References: <20050526171042.5259.qmail@xuxa.iecc.com> <42960E85.7070503@ashtonwoodshomes.com> <42961AAF.5070005@ashtonwoodshomes.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org Cc: wayne@schlitt.net X-Gmane-NNTP-Posting-Host: du-001-212.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Terry Fielder wrote in mxcomp: >> Unless I'm mistaken SPF pass is specific per scope/identity >> checked and there is no overall SPF pass. > That was not my understanding, but I accept being corrected > if that's the case. The only "overall" thing in the actual draft is a HELO FAIL. Hm... or it used to be in -00, -01pre1, -01pre2, -01pre3, -01pre4, -01pre5, but was dropped in -01pre6, -01pre7, -01. Now that's a bug. Wayne, please fix this back, it was no nonsense, I don't recall any debate / resolution about it. And there was no -01pre5 vs. 01pre6 diff, and that's how I missed it. Not talking about HELO FAIL doesn't solve the pending HELO PermError issue. Without an overall HELO FAIL stuff like op=helo needs to be checked, e.g. do we _need_ it ? It's almost what Carl wants: http://purl.net/xyzzy/home/test/draft-spf-6-3-options-06.txt Bye, Frank From owner-ietf-mxcomp@mail.imc.org Thu May 26 16:09:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05293 for ; Thu, 26 May 2005 16:09:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QJnhPp073039; Thu, 26 May 2005 12:49:43 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QJnhvw073038; Thu, 26 May 2005 12:49:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.schlitt.net (schlitt.net [67.52.51.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QJngsn073031 for ; Thu, 26 May 2005 12:49:42 -0700 (PDT) (envelope-from wayne@schlitt.net) Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1DbOMJ-0005Qb-6q for ietf-mxcomp@imc.org; Thu, 26 May 2005 14:49:41 -0500 To: "IETF MARID WG" References: <20050526170838.3089.qmail@xuxa.iecc.com> <42960F81.3010706@ashtonwoodshomes.com> <20050526142311.O9890@simone.iecc.com> <42961FE3.2060303@ashtonwoodshomes.com> From: wayne Mail-Copies-To: nobody Reply-To: "IETF MARID WG" Content-Type: text/plain; charset=US-ASCII Date: Thu, 26 May 2005 14:49:34 -0500 In-Reply-To: <42961FE3.2060303@ashtonwoodshomes.com> (Terry Fielder's message of "Thu, 26 May 2005 15:13:39 -0400") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; problem=; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: SPF and HELO, was Re: SPF PASS X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on backbone.schlitt.net X-Spam-Status: No, score=-6.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <42961FE3.2060303@ashtonwoodshomes.com> Terry Fielder writes: > wayne wrote: >> In <20050526142311.O9890@simone.iecc.com> "John L" writes: >> >>>Could you show me the SPF records I would use to indicate that >>>mta.example,com is valid as an EHLO but not as a bounce address domain >>>while example.com is a valid bounce address domain but not an EHLO. >> >> [example snipped] > > I stand corrected, it can be done with SPFv1, hats off to Wayne (and I > am going to keep this one for myself to use :) I first learned this trick from Greg Connor. I'm not sure if others realized it could be done earlier or independantly. > BTW Ugly as sin is irrelevant, once setup only computers need to read > it, and it can be as ugly and cryptic as necessary, as long as *it > works*. Yeah, but I still don't see the point. Configure your MTA to use the right HELO domain, and configure your MTA to reject email claiming to be from the MTA's host name, and you can just use normal SPF records. Spammers can't abuse either name because they can't send email from the right IP addresses. -wayne From owner-ietf-mxcomp@mail.imc.org Thu May 26 16:10:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23720 for ; Thu, 26 May 2005 15:20:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QJ44AZ069044; Thu, 26 May 2005 12:04:04 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QJ44gv069043; Thu, 26 May 2005 12:04:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QJ43aj069035 for ; Thu, 26 May 2005 12:04:03 -0700 (PDT) (envelope-from terry@ashtonwoodshomes.com) Received: from [10.243.102.72] ([216.191.52.74]) (authenticated bits=0) by mail.greatgulfhomes.com (8.12.8/8.12.8) with ESMTP id j4QJ4iGk013339; Thu, 26 May 2005 15:04:45 -0400 Message-ID: <42961DD3.1080902@ashtonwoodshomes.com> Date: Thu, 26 May 2005 15:04:51 -0400 From: Terry Fielder User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John L CC: ietf-mxcomp@imc.org Subject: Re: SPF and HELO, was Re: SPF PASS References: <20050526170838.3089.qmail@xuxa.iecc.com> <42960F81.3010706@ashtonwoodshomes.com> <20050526142311.O9890@simone.iecc.com> <4296181A.40806@ashtonwoodshomes.com> <20050526145228.N10044@simone.iecc.com> In-Reply-To: <20050526145228.N10044@simone.iecc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit John L wrote: >>> Could you show me the SPF records I would use to indicate that >>> mta.example.com is valid as an EHLO but not as a bounce address >>> domain while example.com is a valid bounce address domain but not an >>> EHLO. If it'll help, assume they both have an A record of 12.34.56.78. >> >> >> You cannot with SPFv1 (based on your assumption). You missed the >> point: It doesn't matter, primarily the HELO is only checked if the >> MAIL FROM fails. >> >> A pass from the HELO or MAIL FROM results in SPF PASS status. > > > My point, which I would have thought was obvious, is that SPF provides > no way to say that EHLO example.com or MAIL FROM: > are invalid. In practice, I see quite a lot of forged mail like that, > and SPF's inability to deal with it is a significant problem. Yes, and if people could write the final version the first time then, well, they wouldn't need versions, would they. It's not that you don't want SPF, you just want it to do more. Stay on board, there are good things coming once they get past the SPFv1 spec. Terry > > Regards, > John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for > Dummies", > Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor > "I dropped the toothpaste", said Tom, crestfallenly. > -- Terry Fielder terry@greatgulfhomes.com Associate Director Software Development and Deployment Great Gulf Homes / Ashton Woods Homes Fax: (416) 441-9085 From owner-ietf-mxcomp@mail.imc.org Thu May 26 16:10:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23704 for ; Thu, 26 May 2005 15:20:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QJ3wZn069025; Thu, 26 May 2005 12:03:58 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QJ3wwl069024; Thu, 26 May 2005 12:03:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.schlitt.net (schlitt.net [67.52.51.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QJ3vQJ069018 for ; Thu, 26 May 2005 12:03:57 -0700 (PDT) (envelope-from wayne@schlitt.net) Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1DbNdy-0004MP-Al for ietf-mxcomp@imc.org; Thu, 26 May 2005 14:03:57 -0500 To: "IETF MARID WG" References: <20050526170838.3089.qmail@xuxa.iecc.com> <42960F81.3010706@ashtonwoodshomes.com> <20050526142311.O9890@simone.iecc.com> From: wayne Mail-Copies-To: nobody Reply-To: "IETF MARID WG" Content-Type: text/plain; charset=US-ASCII Date: Thu, 26 May 2005 14:03:45 -0500 In-Reply-To: <20050526142311.O9890@simone.iecc.com> (John L.'s message of "26 May 2005 14:28:04 -0400") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: SPF and HELO, was Re: SPF PASS X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on backbone.schlitt.net X-Spam-Status: No, score=-6.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <20050526142311.O9890@simone.iecc.com> "John L" writes: >>> Yeah. Too bad that among SPF's many flaws is that it completely >>> confuses the HELO domain and the MAIL FROM domain >> No it does not. It checks each independently. See my previous post >> to your question. > > Could you show me the SPF records I would use to indicate that > mta.example,com is valid as an EHLO but not as a bounce address domain > while example.com is a valid bounce address domain but not an EHLO. > If it'll help, assume they both have an A record of 12.34.56.78. I'll start off by not answering your quesiton. ;-) Personally, I would recommend just publishing these SPF records: example.com TXT "v=spf a -all" mta.example.com TXT "v=spf a -all" If you trust the host 12.34.56.78 enough to authorize it to use both the example.com and mta.example.com domain names, why wouldn't you trust it enough to use them in the right context? Ok, now I'll actually answer your question: example.com TXT "v=spf1 redirect=%{i}._spf.%{d}" postmaster._spf.example.com TXT "v=spf1 -all" *._spf.example.com TXT "v=spf1 a -all" mta.example.com TXT "v=spf1 redirect=%{i}._spf.%{d}" postmaster._spf.mta.example.com TXT "v=spf1 a -all" *._spf.mta.example.com TXT "v=spf1 -all" ugly as sin, and it means that you can't send email using the postmaster local part, but other wise it works and is well defined back to Dec 2003 (or earlier). -wayne From owner-ietf-mxcomp@mail.imc.org Thu May 26 16:19:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08319 for ; Thu, 26 May 2005 16:19:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QK2YHk077220; Thu, 26 May 2005 13:02:34 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QK2Yre077219; Thu, 26 May 2005 13:02:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QK2Y4W077210 for ; Thu, 26 May 2005 13:02:34 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id CDF8F414F5 for ; Thu, 26 May 2005 13:02:28 -0700 (PDT) Subject: draft-schlitt-spf-classic-01.txt From: Douglas Otis To: MARID Content-Type: text/plain Date: Thu, 26 May 2005 13:02:25 -0700 Message-Id: <1117137745.7537.157.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit My previous message was to explain why the MARID reflector is being used for these comments. SPF could offer white-listing utility, provided there is consensus on the record's scope. Such use requires that this scope be defined, or not used as a basis for accruing reputations. Of course, this would make SPF useless for anything other than white-listing. Nor would I trust anyone to honor such exclusion. However, SPF proponents still insist this mechanism is fair with respect to assessing reputations. I say it is fundamentally flawed, as assumptions of assured identifiers place domain owners in serious jeopardy. The email provider must be held accountable in any meaningful approach for abating abuse. However, SPF avoids such accountability. A provider may feel SPF based reputation systems are of little concern to them, but it should be of tremendous concern for their customers, who are often little more than domain owners. Only signatures offer domain owners a modicum of control and oversight in their pursuit of protecting their domain's reputation. Be that as it may, I see this effort as reducing the harm created by SPF. : < 1. Introduction ,---- | The current e-mail infrastructure has the property that any host | injecting mail into the mail system can identify itself as any domain | name it wants. Hosts can do this at a variety of levels: in | particular, the session, the envelope, and the mail headers. While | this feature is desirable in some circumstances, it is a major | obstacle to reducing Unsolicited Bulk E-mail (UBE, aka "spam"). | Furthermore, many domain name holders are understandably concerned | about the ease with which other entities may make use of their domain | names, often with malicious intent. '---- This paragraph lists many different identities that could be used to identify the sender, and implies any could be examined to discover possible server authorization. As just mentioned, some still consider this provides a method for performing sender authentication. These same individuals will happily block any such domains, once they are assumed abusers. After all, abusers can and will also publish SPF records. A disagreement regarding which of these identifiers MUST be assured by the sending server (to protect their client's reputation) occurs within this draft and the draft-lyon-senderid-core-01.txt. It is amazing that this happens even though both of these drafts share the same author. Of course, protecting one's reputation depends upon this important detail. However this draft only defines use of MAILFROM within the message, and ignores this rather serious concern. This is not FUD, this is just F. : ) Unless providers can assure their customers that there are no conflicts within all message PRAs, any other customer would be allowed to create serious harm. This harm could originate from a Zombied computer of such a customer. The abuser may utilize SPF records to obfuscate where the message originates to prolong their success, when seeing such messages are not blocked by the sending server. SPF based reputation systems could employ local or divergent databases that attribute domain abuse based upon the "assumed" sender. (I want to say based upon "Sender Assumptication.") How can the domain owner restore the use of their domain, after their provider naively believes they can assume how a record will be interpreted which has an undefined scope? Wouldn't providers be negligent when advising the use of SPF and not making strict PRA validations? Publication of a dummy record for PRA, which may cause loss of messages, does not seem a satisfactory solution, as provided in the Sender-ID draft. 10.2. SPF-Authorized E-Mail May Be UBE ,---- | The "MAIL FROM" and "HELO" identity authorizations must not be | construed to provide more assurance than they do. It is entirely | possible for a malicious sender to inject a message using their own | domain in the identities used by SPF, to have that domain's SPF | record authorize the sending host, and yet the message content can | easily claim other identities in the headers. Unless the user or the | MUA takes care to note that the authorized identity does not match | the other more commonly-presented identities (such as the From: | header), the user may be lulled into a false sense of security. '---- An interesting, albeit fuzzy, warning indeed. Add another warning of a similar nature. Because there may be an assumption made regarding server "authorization" (even potentially a neutral authorization) being equivalent to sender "authentication," your domain may be attributed for abuse which forges any identifiers other than MAILFROM. Microsoft describes a PRA process based upon this specific SPF record, used in conjunction with SmartScreen, for example. This creates the potential for serious harm to the domain owner's reputation, when providers ignore potential PRA conflicts. Add a warning that examination of the PRA is REQUIRED for cases where the recipient uses draft-lyon-senderid-core-01.txt, which only utilize the record syntax described in this draft. Publishing an SPF record will not ensure which identifier will be held accountable for abuse. If your email-provider does not license the PRA algorithm, there should be no expectation that your domain's reputation is being protected. I'll be happy to agree with Carl about the white-listing utility of an SPF record. To repair this draft, there appears little choice, but to adopt the later version of the SPF record which includes the scope of the identifiers assured by the sender. That was the reason for including scope in the first place. Ignoring this issue would be ignoring a rather big elephant in the room. It would also represent serious negligence on the part of the provider. 10. Security Considerations ,---- | SPF implementations SHOULD limit the total amount of data obtained | from the DNS queries. For example, when DNS over TCP or EDNS0 are | available, there may need to be an explicit limit to how much data | will be accepted to prevent excessive bandwidth usage or memory | usage, and DoS attacks. | | MTAs or other processors MAY also impose a limit on the maximum | amount of elapsed time to evaluate check_host(). Such a limit SHOULD | allow at least 20 seconds. If such a limit is exceeded, the result | of authorization SHOULD be "TempError". '---- With this draft mandating more than one hundred DNS lookups, this raises a concern regarding how the 20 second time limit is employed. A local recursive DNS resolver may act as a UDP amplifier. Congestion avoidance depends upon the application making the requests to wait, in order to maintain stability. There should be some language that warns against doing these many lookups in parallel, and simply timing out the effort to resolve server authorization for a particular message. If parsing routines have not made these provisions, then setting up a two-tier DNS resolver where the Internet facing DNS resolver is not recursive and is rate limited on port 53, could offer a solution. There should also be a warning about acceptance of duplicate records. The same two-tier approach would offer protection when older DNS resolvers are being used that do not ensure replicate lookups are prevented. -Doug From owner-ietf-mxcomp@mail.imc.org Thu May 26 16:23:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08738 for ; Thu, 26 May 2005 16:23:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QFe5Bk023731; Thu, 26 May 2005 08:40:05 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QFe50t023730; Thu, 26 May 2005 08:40:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from imo-m18.mx.aol.com (imo-m18.mx.aol.com [64.12.138.208]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QFe5bu023722 for ; Thu, 26 May 2005 08:40:05 -0700 (PDT) (envelope-from CDHutzler@aol.com) Received: from CDHutzler@aol.com by imo-m18.mx.aol.com (mail_out_v38_r1.7.) id z.f6.51595603 (15874); Thu, 26 May 2005 11:40:00 -0400 (EDT) Received: from [10.180.64.10] ([10.180.64.10]) by air-id07.mx.aol.com (v106.2) with ESMTP id MAILINID71-3e024295edcf108; Thu, 26 May 2005 11:39:59 -0400 Message-ID: <4295EDCF.4020707@aol.com> Date: Thu, 26 May 2005 11:39:59 -0400 From: Carl Hutzler User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: william@elan.net CC: Andrew Newton , ietf-mxcomp@imc.org Subject: Re: SPF PASS (was: "If you believe that the SPF concept is fundam entally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/") References: <114DE040D7A6524E9C3B000F47CCD8BD0C450C1A@S2U.LOCAL> <55a5ed639e56e4e706aef879165b476e@hxr.us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 10.180.64.10 X-Mailer: Unknown (No Version) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I wish there was a way to utilize the relatively large number of SPF records in a technology like CSV. -Carl From owner-ietf-mxcomp@mail.imc.org Thu May 26 16:24:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08852 for ; Thu, 26 May 2005 16:24:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QJwCL1076888; Thu, 26 May 2005 12:58:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QJwCdt076887; Thu, 26 May 2005 12:58:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.schlitt.net (schlitt.net [67.52.51.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QJw6PF076878 for ; Thu, 26 May 2005 12:58:11 -0700 (PDT) (envelope-from wayne@schlitt.net) Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1DbOUP-0005Yq-SI for ietf-mxcomp@imc.org; Thu, 26 May 2005 14:58:05 -0500 To: "IETF MARID WG" References: <200505260302.49515.bulk@mehnle.net> <200505261315.j4QDFtoB048070@asarian-host.net> From: wayne Mail-Copies-To: nobody Reply-To: "IETF MARID WG" Content-Type: text/plain; charset=US-ASCII Date: Thu, 26 May 2005 14:57:57 -0500 In-Reply-To: (Richard Clayton's message of "Thu, 26 May 2005 19:53:32 +0100") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on backbone.schlitt.net X-Spam-Status: No, score=-6.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In Richard Clayton writes: > I repeat my advice from another place to give up proselytising how SPF > will make a better world and just concentrate on a comprehensible, > interworkable standard that doesn't break anything else. If it then > turns out to have magical powers and cures cancer and stuff then that's > peachy. But its unnecessary to promote that up front. I tend to agree with you. Unfortunately, one of the problems with open projects that have no membership requirements and only vague leadership roles is that anyone can say anything and still claim to be part of the community. The membership requirements to be in the SPF community is slightly less strict than the membership for the IETF, but the organization of the SPF community is far less formal than the IETF. -wayne From owner-ietf-mxcomp@mail.imc.org Thu May 26 16:24:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08879 for ; Thu, 26 May 2005 16:24:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QK82bD077644; Thu, 26 May 2005 13:08:03 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QK82H6077643; Thu, 26 May 2005 13:08:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from imo-m18.mx.aol.com (imo-m18.mx.aol.com [64.12.138.208]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QK82re077636 for ; Thu, 26 May 2005 13:08:02 -0700 (PDT) (envelope-from CDHutzler@aol.com) Received: from CDHutzler@aol.com by imo-m18.mx.aol.com (mail_out_v38_r1.7.) id e.1f8.a909f6f (16035); Thu, 26 May 2005 16:07:39 -0400 (EDT) Received: from [10.180.64.10] ([10.180.64.10]) by air-id10.mx.aol.com (v106.2) with ESMTP id MAILINID102-3ea342962c8b285; Thu, 26 May 2005 16:07:39 -0400 Message-ID: <42962C8B.3080108@aol.com> Date: Thu, 26 May 2005 16:07:39 -0400 From: Carl Hutzler User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hsantos@santronics.com CC: william@elan.net, Andrew Newton , ietf-mxcomp@imc.org Subject: Re: Addressing Backward Compatibility [was Re: SPF PASS] References: <114DE040D7A6524E9C3B000F47CCD8BD0C450C1A@S2U.LOCAL> <55a5ed639e56e4e706aef879165b476e@hxr.us> <4295EDCF.4020707@aol.com> <008d01c56219$0ccd9030$6401a8c0@hdev1> In-Reply-To: <008d01c56219$0ccd9030$6401a8c0@hdev1> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 10.180.64.10 X-Mailer: Unknown (No Version) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit hsantos@santronics.com wrote: >----- Original Message ----- >From: "Carl Hutzler" >Sent: Thursday, May 26, 2005 11:39 AM >Subject: Re: SPF PASS > > > >>I wish there was a way to utilize the relatively large number of SPF >>records in a technology like CSV. >> >>-Carl >> >> > >The basic issue with all of this is not a specific methodology can work or >not work, but rather the basic fact that none of it can be enforced. > >So even if all the kinks were solved in SPF, CSV, FUZZ, ABC or what have >you, SMTP developers, such as yourself, myself and others will still be >stuck with still ACCEPTING the non-compliant senders and/or dealing with >legacy issues. > >It doesn't make sense. The only, and I mean only reason I implemented SPF >was two reasons: > >1) AOL.COM announced support from a domain standpoint. AOL being one of the >greatest sources of spam (spoofed or otherwise), we need something from AOL >to help all the other victim systems. So once AOL.COM announce SPF support >by publishing a SPF domain, we immediately started to implement SPF, and >guess what, the AOL announcement also made MICROSOFT jump and in my view, >was the reason MARID eventually started > >2) SPF would be part of a suite of other methods, in particular ONE method >that has no dependency with "new" information being available - this is the >CBV, the call back verifier. > >The CBV is 100% based on the idea that "ok, we don't have much to go on, but >at the VERY least, from a SMTP BOUNCE compliancy standpoint, the return >path must be valid. It may be spoofed, it may be a zombie, but it must be >valid. It can not be junk." > >So we explored the CBV. I am not saying it is the "answer" but what it >proved was one fundamental aspect of the problem we are trying to address: > > That indeed, the majority, by atleast 60-80% of all transactions > are non-compliant from a SMTP standpoint. > >Period. No ands, ifs or butts. And it should not be a SURPRISE to anyone >because it is the reason why we have the problem in the first place. > >So what's missing from the process? > >We need an anchor that exist today to address the backward compatibility >issue. We don't really have a consensus on what uniquely identifies a MAIL >sender or machine that is part of a mail domain. > >So we can debate, argue left and right, we are still left with the same old >issue on how to address backward compatibility. > >Until someone can address this, all the proposals are for the most part >worthless. > >This is the secret the spammers don't want us to discover and realize, >because until we do, they have no reason for them to change or adapt. > >SPF can work if everyone was forced to use SUBMITTER like idea to address >the transitional domain/ip changes. > >CSV can work if everyone was forced to use reliable client domain name. > >etc, etc, but as long as it is not "REQUIRED" or enforceable, it is all >worthless. > >So Carl, how can we enforce these proposals? How do I enforce CSV support? > >No, I am not encouraging "POLICY" discussions. I am talking about how can >we automate the framework of a mixed hetergeneous network of systems? > >I have a few ideas. > >-- >Hector Santos, Santronics Software, Inc. >http://www.santronics.com > > > > > > > So if AOL began doing CSV, then everyone would follow? Hmmm, it might help, but not sure that's a given. -- Carl Hutzler Director, Host Mail Development America Online cdhutzler@aol.com 703.265.5521 work 703.915.6862 cell From owner-ietf-mxcomp@mail.imc.org Thu May 26 16:29:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09463 for ; Thu, 26 May 2005 16:29:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QKD8X6078092; Thu, 26 May 2005 13:13:08 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QKD8sI078091; Thu, 26 May 2005 13:13:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from aismt08p.bellsouth.com (aismt08p.bellsouth.com [139.76.165.215]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QKD73m078072 for ; Thu, 26 May 2005 13:13:07 -0700 (PDT) (envelope-from damon.sauer@bellsouth.com) Received: from ([90.152.53.181]) by aismt08p.bellsouth.com with SMTP id KP-AXPNC.40077563; Thu, 26 May 2005 16:12:40 -0400 Importance: normal Received: from 01AL10015010045.ad.bls.com ([90.152.5.71]) by 01AL10015010162.ad.bls.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 26 May 2005 15:12:39 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Subject: RE: SPF and HELO, was Re: SPF PASS Date: Thu, 26 May 2005 15:12:39 -0500 Message-ID: Thread-Topic: SPF and HELO, was Re: SPF PASS Thread-Index: AcViJ1M/auOAo9wSSBOwz6BHebJE0AAB2KeA From: "Sauer, Damon" To: "Terry Fielder" , "IETF MARID WG" X-OriginalArrivalTime: 26 May 2005 20:12:39.0768 (UTC) FILETIME=[443BC580:01C5622F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4QKD73m078086 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > I stand corrected, it can be done with SPFv1, hats off to Wayne (and I > am going to keep this one for myself to use :) > BTW Ugly as sin is irrelevant, once setup only computers > need to read > it, and it can be as ugly and cryptic as necessary, as long > as *it works*. > > Terry > And I am going to keep this one for the next time I have to explain my perl code :P I guess nobody remembers programming on a Commodore? :D Regards, Damon Sauer ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162 From owner-ietf-mxcomp@mail.imc.org Thu May 26 16:34:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09903 for ; Thu, 26 May 2005 16:34:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QKF2bt078244; Thu, 26 May 2005 13:15:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QKF2Hc078243; Thu, 26 May 2005 13:15:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from backbone.schlitt.net (schlitt.net [67.52.51.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QKF1HJ078237 for ; Thu, 26 May 2005 13:15:01 -0700 (PDT) (envelope-from wayne@schlitt.net) Received: from footbone.schlitt.net ([67.52.51.37] helo=schlitt.net) by backbone.schlitt.net with esmtp (Exim 4.50) id 1DbOkn-0005sA-UW for ietf-mxcomp@imc.org; Thu, 26 May 2005 15:15:01 -0500 To: "IETF MARID WG" References: <20050526171042.5259.qmail@xuxa.iecc.com> <42960E85.7070503@ashtonwoodshomes.com> <42961AAF.5070005@ashtonwoodshomes.com> <4296248E.10D2@xyzzy.claranet.de> From: wayne Mail-Copies-To: nobody Reply-To: "IETF MARID WG" Content-Type: text/plain; charset=US-ASCII Date: Thu, 26 May 2005 15:14:53 -0500 In-Reply-To: <4296248E.10D2@xyzzy.claranet.de> (Frank Ellermann's message of "Thu, 26 May 2005 21:33:34 +0200") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Received-SPF: pass (backbone.schlitt.net: domain of schlitt.net designates 67.52.51.37 as permitted sender) client-ip=67.52.51.37; envelope-from=wayne@schlitt.net; helo=schlitt.net; problem=; X-SA-Exim-Connect-IP: 67.52.51.37 X-SA-Exim-Rcpt-To: ietf-mxcomp@imc.org X-SA-Exim-Mail-From: wayne@schlitt.net Subject: Re: SPF PASS X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on backbone.schlitt.net X-Spam-Status: No, score=-6.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.2 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on backbone.schlitt.net) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <4296248E.10D2@xyzzy.claranet.de> Frank Ellermann writes: > Terry Fielder wrote in mxcomp: > >>> Unless I'm mistaken SPF pass is specific per scope/identity >>> checked and there is no overall SPF pass. > >> That was not my understanding, but I accept being corrected >> if that's the case. > > The only "overall" thing in the actual draft is a HELO FAIL. > > Hm... or it used to be in -00, -01pre1, -01pre2, -01pre3, > -01pre4, -01pre5, but was dropped in -01pre6, -01pre7, -01. > > Now that's a bug. Wayne, please fix this back, it was no > nonsense, I don't recall any debate / resolution about it. There was debate about it. It is mentioned in the release notes. What happened is that, as part of restoring the HELO checking from draft-mengwong-spf-0[01], I copied that sentence into draft-schlitt-spf-classic-00. However, that sentence was originally part of a "RECOMMENDED algorithm", so copying that sentence caused a change in semantics. The whole "RECOMMENDED algoright" has been dropped. It is Receiver Policy anyway, not Sender Policy. -wayne From owner-ietf-mxcomp@mail.imc.org Thu May 26 16:49:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11012 for ; Thu, 26 May 2005 16:49:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QKTTOr079396; Thu, 26 May 2005 13:29:29 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QKTTp3079395; Thu, 26 May 2005 13:29:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QKTSuM079387 for ; Thu, 26 May 2005 13:29:28 -0700 (PDT) (envelope-from scott@kitterman.com) Received: from [64.32.194.73] (HELO wsd865gbf) by fe.mail.megapathdsl.net (CommuniGate Pro SMTP 4.2.10) with SMTP id 280023555 for ietf-mxcomp@imc.org; Thu, 26 May 2005 13:29:23 -0700 From: "Scott Kitterman" To: Subject: RE: SPF PASS (was: "If you believe that the SPF concept is fundam entally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/") Date: Thu, 26 May 2005 16:29:23 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <4295EDCF.4020707@aol.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >-----Original Message----- >From: owner-ietf-mxcomp@mail.imc.org >[mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Carl Hutzler >Sent: Thursday, May 26, 2005 11:40 AM >To: william@elan.net >Cc: Andrew Newton; ietf-mxcomp@imc.org >Subject: Re: SPF PASS (was: "If you believe that the SPF concept is >fundam entally flawed, please subscribe at >http://www.imc.org/ietf-mxcomp/") > > > >I wish there was a way to utilize the relatively large number of SPF >records in a technology like CSV. > >-Carl > > What would be the advantage, from your perspective, to doing that instead of using the HELO checking approach already defined in SPF? Scott Kitterman From owner-ietf-mxcomp@mail.imc.org Thu May 26 16:51:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11240 for ; Thu, 26 May 2005 16:51:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QKYm4h079961; Thu, 26 May 2005 13:34:48 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QKYmlV079960; Thu, 26 May 2005 13:34:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from imo-m20.mx.aol.com (imo-m20.mx.aol.com [64.12.137.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QKYmRQ079945 for ; Thu, 26 May 2005 13:34:48 -0700 (PDT) (envelope-from CDHutzler@aol.com) Received: from CDHutzler@aol.com by imo-m20.mx.aol.com (mail_out_v38_r1.7.) id 5.1a0.349dd3f9 (16097); Thu, 26 May 2005 16:34:39 -0400 (EDT) Received: from [10.180.64.10] ([10.180.64.10]) by air-id11.mx.aol.com (v106.2) with ESMTP id MAILINID111-3ee1429632de58; Thu, 26 May 2005 16:34:39 -0400 Message-ID: <429632DE.2000803@aol.com> Date: Thu, 26 May 2005 16:34:38 -0400 From: Carl Hutzler User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: scott@kitterman.com CC: ietf-mxcomp@imc.org Subject: Re: SPF PASS (was: "If you believe that the SPF concept is fundam entally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/") References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AOL-IP: 10.180.64.10 X-Mailer: Unknown (No Version) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit scott@kitterman.com wrote: >>-----Original Message----- >>From: owner-ietf-mxcomp@mail.imc.org >>[mailto:owner-ietf-mxcomp@mail.imc.org]On Behalf Of Carl Hutzler >>Sent: Thursday, May 26, 2005 11:40 AM >>To: william@elan.net >>Cc: Andrew Newton; ietf-mxcomp@imc.org >>Subject: Re: SPF PASS (was: "If you believe that the SPF concept is >>fundam entally flawed, please subscribe at >>http://www.imc.org/ietf-mxcomp/") >> >> >> >>I wish there was a way to utilize the relatively large number of SPF >>records in a technology like CSV. >> >>-Carl >> >> >> >> >What would be the advantage, from your perspective, to doing that instead of >using the HELO checking approach already defined in SPF? > >Scott Kitterman > > > Never even knew there was helo checking in SPF. I might have to do some reading. My bad! -- Carl Hutzler Director, Host Mail Development America Online cdhutzler@aol.com 703.265.5521 work 703.915.6862 cell From owner-ietf-mxcomp@mail.imc.org Thu May 26 17:15:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13113 for ; Thu, 26 May 2005 17:15:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QKhLap080519; Thu, 26 May 2005 13:43:21 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QKhLfB080518; Thu, 26 May 2005 13:43:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QKhJf5080509 for ; Thu, 26 May 2005 13:43:19 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1DbP9a-0003nO-Bp for ietf-mxcomp@imc.org; Thu, 26 May 2005 22:40:30 +0200 Received: from du-001-212.access.de.clara.net ([212.82.227.212]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 May 2005 22:40:30 +0200 Received: from nobody by du-001-212.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 May 2005 22:40:30 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: SPF and SenderID Date: Thu, 26 May 2005 22:30:52 +0200 Organization: Lines: 27 Message-ID: <429631FC.4F6F@xyzzy.claranet.de> References: <4295C2D0.1000801@234.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-212.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Cc: spf-help@v2.listbox.com Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Pete Chown wrote in spf-help: > What should I do now? Is there a way of supporting SPF > without helping to get a patented technology established > on the Internet? Sure. MS pretends to control spf2.0/pra to a certain degree, as defined in draft-lyon-senderid-pra-01 They certainly don't control all of spf2.0, as defined in draft-lyon-senderid-core-01 They never controlled a single bit of v=spf1 as defined in draft-schlitt-spf-classic-01 As long as you don't want PRA this doesn't affect you, v=spf1 is an open standard (wannabe from the IETF's POV, there's yet no RfC for it). MS tried to pull the stunt that v=spf1 is by default a part of PRA. This is a lie, the IESG knows that it's a lie, so senderid-lyon-core-01 can never pass as an RfC. Bye, Frank (Cc: mxcomp) From owner-ietf-mxcomp@mail.imc.org Thu May 26 17:23:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13622 for ; Thu, 26 May 2005 17:23:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QGgPZ1033764; Thu, 26 May 2005 09:42:25 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QGgPjP033763; Thu, 26 May 2005 09:42:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QGgOrX033755 for ; Thu, 26 May 2005 09:42:25 -0700 (PDT) (envelope-from richard@highwayman.com) Received: from gti.noc.demon.net ([195.11.55.101] helo=happyday.al.cl.cam.ac.uk) by anchor-post-32.mail.demon.net with esmtp (Exim 4.42) id 1DbLRA-0007VJ-6o for ietf-mxcomp@imc.org; Thu, 26 May 2005 16:42:24 +0000 Message-ID: Date: Thu, 26 May 2005 17:41:20 +0100 To: ietf-mxcomp@imc.org From: Richard Clayton Subject: Re: "If you believe that the SPF concept is fundamentally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/" References: <200505260302.49515.bulk@mehnle.net> <200505261315.j4QDFtoB048070@asarian-host.net> In-Reply-To: <200505261315.j4QDFtoB048070@asarian-host.net> MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.02 M <7s+$+nxz77vLpNKL1id+d+$rfK> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In article <200505261315.j4QDFtoB048070@asarian-host.net>, Mark writes >To sum it up: > >1): Spammers causing their registered domains to "pass", only identify and >set themselves up to be block-listed. so it would be foolish of them to keep on using their domains >2): Email sent with reputable domains, used without authorization by >spammers, so they can't borrow domains and send the email from their machines with you so far :) >are protected -- hence exempt from erroneously being counted >towards spam and bad reputation! Hence, since they still want to spam, they will start sending email with borrowed domains from borrowed machines... they are already doing the latter, they don't do the former because there's currently no need. SPF would, if adopted, provide the evolutionary pressure for them to do so. Of course you may feel that if fred@example.com is so dumb as to install a spam-sending trojan that it serves him right if example.com gets a really bad reputation. However, if I have a need to swap email with example.com employees how exactly has SPF improved the situation here ? Seems to me SPF might have a few advantages relating to back-scatter but that too much email is being forwarded for that to work out in the near future. However, promoting it on the basis that spammers will not change their behaviour doesn't seem to be justified. Or have I missed something, and if so what ? - -- richard Richard Clayton They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. Benjamin Franklin -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBQpX8MJoAxkTY1oPiEQLfmgCfTGRplsq1GIR6Xc722s6Y2GA89SwAn2tg 8fKa6b9HUVdh0m+vHO3KROXJ =aCw8 -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Thu May 26 17:32:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14581 for ; Thu, 26 May 2005 17:32:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QLCakm095912; Thu, 26 May 2005 14:12:36 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QLCaTU095903; Thu, 26 May 2005 14:12:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QLCXhU095893 for ; Thu, 26 May 2005 14:12:34 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DbPas-0007bJ-Cg for ietf-mxcomp@imc.org; Thu, 26 May 2005 23:08:42 +0200 Received: from du-001-212.access.de.clara.net ([212.82.227.212]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 May 2005 23:08:42 +0200 Received: from nobody by du-001-212.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 26 May 2005 23:08:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: overall HELO FAIL (was: SPF PASS) Date: Thu, 26 May 2005 23:05:10 +0200 Organization: Lines: 34 Message-ID: <42963A06.7FCA@xyzzy.claranet.de> References: <20050526171042.5259.qmail@xuxa.iecc.com> <42960E85.7070503@ashtonwoodshomes.com> <42961AAF.5070005@ashtonwoodshomes.com> <4296248E.10D2@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-212.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit wayne wrote: > There was debate about it. MID ? Any _comma_ changed with the results is important. It's only luck that I tried grep 'overall' while writing a reply to Terry / William. > It is mentioned in the release notes. | Removed e-mail receiver policy definition on how to handle | HELO checking. It was copied incorrectly from | draft-mengwong-spf-01, changing its meaning. Yes, obviously I didn't get the meaning of this part by only reading the diff. > It is Receiver Policy anyway, not Sender Policy. Curious senders might wish to kow what the expected effect of a HELO FAIL is. Curious implementors might also wish to know what to do in this case. And if curious admins like Terry consider to test MAIL FROM before HELO they waste time if it is a HELO FAIL. No receiver policy in the spec. is fine, but please don't get carried away. For a "who knows what the effect might be" text 100 KB are rather long, and there are already good PRG RfCs not using DNS at all. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Thu May 26 17:34:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14721 for ; Thu, 26 May 2005 17:34:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QLIGwL096474; Thu, 26 May 2005 14:18:16 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QLIGpv096473; Thu, 26 May 2005 14:18:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from io.link-m.de (daemon@io.link-m.de [195.30.85.225]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QLIFni096467 for ; Thu, 26 May 2005 14:18:16 -0700 (PDT) (envelope-from bulk@mehnle.net) Received: from gray.home.mehnle.net (p549A3223.dip.t-dialin.net [::ffff:84.154.50.35]) (AUTH: PLAIN julian@mehnle.net, TLS: TLSv1/SSLv3,128bits,RC4-MD5) by io.link-m.de with esmtp; Thu, 26 May 2005 23:18:14 +0200 id 00000160.42963D16.000063F5 From: Julian Mehnle Reply-To: julian@mehnle.net To: MARID Subject: Re: draft-schlitt-spf-classic-01.txt Date: Thu, 26 May 2005 23:18:03 +0200 User-Agent: KMail/1.7.2 References: <1117137745.7537.157.camel@SJC-Office-DHCP-156.mail-abuse.org> In-Reply-To: <1117137745.7537.157.camel@SJC-Office-DHCP-156.mail-abuse.org> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505262318.03899.bulk@mehnle.net> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks for your review. Douglas Otis wrote: > The email provider must be held accountable in any meaningful approach > for abating abuse. However, SPF avoids such accountability. A provider > may feel SPF based reputation systems are of little concern to them, but > it should be of tremendous concern for their customers, who are often > little more than domain owners. Why do you think ISPs must be held accountable instead of domain owners? > Only signatures offer domain owners a modicum of control and oversight in > their pursuit of protecting their domain's reputation. Why? > 1. Introduction > > [...] > Unless providers can assure their customers that there are no conflicts > within all message PRAs, any other customer would be allowed to create > serious harm. If you are talking of cross-user forgery, see SPF, section 10.4[1]. This isn't something that can generally be solved by an authorization protocol that works with a granularity of IP addresses. If you are talking of something else, I don't know what it is. > This harm could originate from a Zombied computer of such a customer. > The abuser may utilize SPF records to obfuscate where the message > originates to prolong their success, when seeing such messages are not > blocked by the sending server. How could SPF records be used to "obfuscate" a message's origin? The last time I looked, SPF didn't suppress the generation of "Received:" headers. > SPF based reputation systems could employ local or divergent databases > that attribute domain abuse based upon the "assumed" sender. So what? Receivers are already doing the same with IP address white- and black-lists. The world has not gone up in flames, though. > How can the domain owner restore the use of their domain, after their > provider naively believes they can assume how a record will be > interpreted which has an undefined scope? (I assume you aren't implying that the concepts of accountability and reputation are fundamentally flawed.) There are no SPF records with an undefined scope. If, for v=spf1 records, receivers choose to apply Sender-ID's inconsistent scope definition (PRA) over that of SPF itself, is it SPF's fault? Have you complained already to Microsoft and the IESG about Sender-ID redefining v=spf1 records? If not, why do you keep bringing up this issue here? To say that even though this inconsistency is not SPF's fault, another draft can always be employed to destroy its usefulness? What if I submitted a draft to the IETF that conflicted with the DomainKeys specification? Would that make DomainKeys useless (or harmful)? > 10. Security Considerations > > [...] > With this draft mandating more than one hundred DNS lookups, The SPF specification does not "mandate more than one hundred" DNS lookups. It mandates that a receiver must be prepared to perform at most 111 DNS lookups. This does not mean that the usual case is anywhere near that. > this raises a concern regarding how the 20 second time limit is employed. > A local recursive DNS resolver may act as a UDP amplifier. Congestion > avoidance depends upon the application making the requests to wait, in > order to maintain stability. > [...] This sounds like a valid concern. > There should also be a warning about acceptance of duplicate records. What do you mean by "duplicate records"? Again, thanks for your review. Julian. References: 1. http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-01.html#cross-user-forgery -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFClj0LwL7PKlBZWjsRAhApAJ9g9ilciY7849RvdJmzOKTgNQDQbwCgra/0 cPnwKcdhNAt1vPV9RABwSyI= =cUpg -----END PGP SIGNATURE----- From owner-ietf-mxcomp@mail.imc.org Thu May 26 22:57:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08247 for ; Thu, 26 May 2005 22:56:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QLVDVZ097767; Thu, 26 May 2005 14:31:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4QLVDnh097766; Thu, 26 May 2005 14:31:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from tomts10-srv.bellnexxia.net (tomts10.bellnexxia.net [209.226.175.54]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QLVCjs097760 for ; Thu, 26 May 2005 14:31:12 -0700 (PDT) (envelope-from jbglube@sympatico.ca) Received: from ibmrkydk2ufvdd ([67.70.36.203]) by tomts10-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20050526213111.NZN26102.tomts10-srv.bellnexxia.net@ibmrkydk2ufvdd>; Thu, 26 May 2005 17:31:11 -0400 X-IMBH: Yes From: "John Glube" To: "'Carl Hutzler'" Cc: Subject: RE: Addressing Backward Compatibility [was Re: SPF PASS] Date: Thu, 26 May 2005 17:30:42 -0400 Message-ID: <020d01c5623a$2b381c90$6c62fea9@ibmrkydk2ufvdd> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <42962C8B.3080108@aol.com> Importance: Normal Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit |-----Original Message----- |From: owner-ietf-mxcomp@mail.imc.org [mailto:owner-ietf-|mxcomp@mail.imc.org] On Behalf Of Carl Hutzler |Sent: May 26, 2005 4:08 PM |To: hsantos@santronics.com |Cc: william@elan.net; Andrew Newton; ietf-mxcomp@imc.org |Subject: Re: Addressing Backward Compatibility [was Re: SPF |PASS] | | | |So if AOL began doing CSV, then everyone would follow? |Hmmm, it might help, but not sure that's a given. Possibly. However, if AOL were to say those senders who are white listed, or who are applying to be white listed with AOL something like: As part of its ongoing efforts to improve network security and its user's experience, AOL is implementing Certified Server Validation (CSV). We urge all bulk mailers and internet access services who are presently white listed with AOL or who are seeking white listing status with AOL to review this protocol and take the appropriate implementation steps. For more details: At the same time, let it be known within the ISP and marketing industries: * We are implementing Certified Server Validation (CSV). We encourage all bulk mailers and internet access services sending mail to AOL to also implement CSV as appropriate. Presuming you are satisfied that CSV does what you want: * Set up a 'special' white list for those senders who have published CSV records and indicate you plan to merge this with your 'special' white list for those senders who have published SPF records. I believe that would get the ball rolling. As the saying goes, "your wish is my command" :-) John John Glube Toronto, Canada From owner-ietf-mxcomp@mail.imc.org Fri May 27 00:24:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13474 for ; Fri, 27 May 2005 00:24:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4R42Cij005202; Thu, 26 May 2005 21:02:12 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4R42CMM005201; Thu, 26 May 2005 21:02:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4R42B0a005183 for ; Thu, 26 May 2005 21:02:11 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id 06496414F1; Thu, 26 May 2005 21:02:09 -0700 (PDT) Subject: Re: draft-schlitt-spf-classic-01.txt From: Douglas Otis To: julian@mehnle.net Cc: MARID In-Reply-To: <200505262318.03899.bulk@mehnle.net> References: <1117137745.7537.157.camel@SJC-Office-DHCP-156.mail-abuse.org> <200505262318.03899.bulk@mehnle.net> Content-Type: text/plain Date: Thu, 26 May 2005 21:02:08 -0700 Message-Id: <1117166528.30777.16.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 2005-05-26 at 23:18 +0200, Julian Mehnle wrote: > Douglas Otis wrote: > > > The email provider must be held accountable in any meaningful approach > > for abating abuse. However, SPF avoids such accountability. A provider > > may feel SPF based reputation systems are of little concern to them, but > > it should be of tremendous concern for their customers, who are often > > little more than domain owners. > > Why do you think ISPs must be held accountable instead of domain owners? Abating abuse requires diligence. This diligence involves the monitoring of servers. To protect the privacy of other customers, much of an MTA server's operation remains hidden from the domain owner, who is often just one of many typical customers. With SPF reliance on the mailbox-domain, the server's administrator remains anonymous. Negligent server operation will not directly impact the administrator, but instead impacts the domain owner. A reputation system should hold accountable those who are expected to maintain diligence in respect to security, access, and operation. Holding an innocent, feckless party accountable is simply an unfair practice. Dare I say even foolish? By the time a domain owner is made aware that volumes of abuse has emerged from some SPF authorized server, forging their mailbox-domain in some unexpected header, the reputation of their domain may have become unsuitable for email. The means to recoup their reputation in this situation may not be practical. The domain owner may be innocent. They may also view their domain as highly valuable. They may also be required to seek expensive legal avenues to uncover the cause of their dilemma. With SPF building upon a filtering paradigm, there may be no outward indication their messages are being silently dropped or placed into junk folders either. It is not clear how the domain owner will recover reliable use of their email domain after publishing SPF and then being exploited. This is a very real concern being completely ignored by providers anxious to rid themselves of their responsibilities with respect to this menacing abuse. Nevertheless, abating abuse requires holding administrators accountable and ensuring they stay on top of security, access, and operational issues. A reputation scheme MUST identify the source of abuse, and not the "assumed" source of abuse. A reputation scheme must hold those responsible, accountable. SPF fails badly on both of these issues. It is folly to think SPF will improve the integrity of email or diminish the rate of abuse. A reputation scheme based upon SPF authorization is certain to dramatically reduce email's integrity for the majority of domain owners. > > Only signatures offer domain owners a modicum of control and oversight in > > their pursuit of protecting their domain's reputation. > > Why? By retaining a signature operation within their administrative control, the domain owner would have far greater control over the fate of their domain's reputation. They could utilize the services of an email provider to relay email from a dynamic location, without fear other abusive messages may be confused as being from them. If their relay provider was lax at security or preventing abuse, the domain owner can seek a different provider to rectify any resulting problems. You should put yourself into your customer's position. Proclamations that with SPF, some domain can not be forged are specious. This of course assumes closed-ended list, where the domain owner maintains exclusive access to their servers. Closed-ended lists are not practical, nor do most domain owners manage their own MTAs with exclusive access. A domain owner that protects the private portion of their signature, does not depend upon an email provider to protect their reputation. Especially an email provider with dubious motives asking them to publish SPF records. How on Earth can publishing an SPF record be in the interest of the domain owner, after Microsoft proclaims server authorization is the same as sender authentication? A DomainKeys signature associated with the Sender header allows the provider to accept accountability for their customers, without mandating their customers change their email addresses or publish DNS records. The provider could also offer to relay messages already signed by their customers as well. Either of these scenarios would be fair. With prior knowledge of the sender, perhaps in the case where an SPF record is being used to establish a white-list, SPF could offer utility. White-listing may be practical for typical bulk emailers, but not for the majority of email domains. However, DomainKeys could supplant reliance upon white-listing, without the overhead needed to maintain a complex database that may create problematic overlaps. > > 1. Introduction > > > > [...] > > Unless providers can assure their customers that there are no conflicts > > within all message PRAs, any other customer would be allowed to create > > serious harm. > > If you are talking of cross-user forgery, see SPF, section 10.4[1]. This > isn't something that can generally be solved by an authorization protocol > that works with a granularity of IP addresses. You misunderstood the concern. An email provider likely handles customers using many different mailbox-domains. Yes, there could be cross-user forgery within a domain, but that was not the concern. There could also be cross-domain forgery. The provider is expected to make assurances that some range of domains is permitted specifically for those provided access to the MTA. If the provider does not properly authenticate the user (some still exchange passwords in the clear), or does not evaluate the PRA, the domain owner is placed at risk by publishing SPF records. The sender does not know what the recipient uses to base their reputation assessments. Someone can get seriously hurt heedlessly publishing SPF. > If you are talking of something else, I don't know what it is. > > > This harm could originate from a Zombied computer of such a customer. > > The abuser may utilize SPF records to obfuscate where the message > > originates to prolong their success, when seeing such messages are not > > blocked by the sending server. > > How could SPF records be used to "obfuscate" a message's origin? The last > time I looked, SPF didn't suppress the generation of "Received:" headers. Anyone that utilizes a large provider and publishes an SPF record that, in effect, proclaims such use, could enable an abuser to send from the correct server, while still lying about who they are. SPF does not prevent this problem. SPF requires assumed checks that may or may not be performed. In fact, some of these checks may require a license. : ( The abuser may wish to play this game until they have scorched the reputation of that domain, before usurping the identity of the next available victim, all while thanking SPF for making their fun possible. > > SPF based reputation systems could employ local or divergent databases > > that attribute domain abuse based upon the "assumed" sender. > > So what? Receivers are already doing the same with IP address white- and > black-lists. The world has not gone up in flames, though. Quite typically, providers that employ a black-hole listing service, will indicate the website of this service in the error message returned in the session refusal. The person sending the message can opt to immediately try a different provider to send their message. They may also elect to complain to the black-hole listing service that indicated the MTA they utilized is not properly administered. Perhaps the server administration permitted access to the wrong person, perhaps they accidentally enabled an open-proxy in their network, perhaps they even allowed an open-relay. Whatever the problem, the sender often knows where to go for restitution. As SPF is intended to assist the filtering of messages, filtering often employs a practice of placing uncertain results into a junk folder. With SPF, there are many shades of gray. : ( > > How can the domain owner restore the use of their domain, after their > > provider naively believes they can assume how a record will be > > interpreted which has an undefined scope? > > (I assume you aren't implying that the concepts of accountability and > reputation are fundamentally flawed.) The assumption that a mailbox-domain can be authenticated without the use of a signature is fundamentally flawed. Server authorization is far too weak to base a presumption of having authenticated the sender. Server authorization in the manner of SPF also wrecks havoc on email's architecture. There is no reason for this, when signatures require less effort and create less collateral damage. > There are no SPF records with an undefined scope. If, for v=spf1 records, > receivers choose to apply Sender-ID's inconsistent scope definition (PRA) > over that of SPF itself, is it SPF's fault? So are you going to tell a 900 pound gorilla they are wrong? In the end, the gorilla will have their way with you. ; ) > Have you complained already to Microsoft and the IESG about Sender-ID > redefining v=spf1 records? If not, why do you keep bringing up this issue > here? To say that even though this inconsistency is not SPF's fault, > another draft can always be employed to destroy its usefulness? Strange, I see the same author on both drafts? Who's fault is that? Depreciate the use v=spf1 to be assured of avoiding this serious conflict. > What if I submitted a draft to the IETF that conflicted with the DomainKeys > specification? Would that make DomainKeys useless (or harmful)? What patent licensing restrictions would you impose? Are you large enough to make your claims a serious concern? Would you be asking domain owners to fall into a trap, which over time as a ubiquitous reputation program is applied, necessitates domain owners find providers that license your scheme? > > 10. Security Considerations > > > > [...] > > With this draft mandating more than one hundred DNS lookups, > > The SPF specification does not "mandate more than one hundred" DNS lookups. > It mandates that a receiver must be prepared to perform at most 111 DNS > lookups. This does not mean that the usual case is anywhere near that. Odd, but I see a required minimum as a mandate, and 111 is more than 100. If there are on average 5 queries created for every lookup, this could mean 555 queries are required to resolve a server's authorization for a single message. > > this raises a concern regarding how the 20 second time limit is employed. > > A local recursive DNS resolver may act as a UDP amplifier. Congestion > > avoidance depends upon the application making the requests to wait, in > > order to maintain stability. > > [...] > > This sounds like a valid concern. > > > There should also be a warning about acceptance of duplicate records. > > What do you mean by "duplicate records"? DNS transactions are only protected by a 16 bit integer. Often routines utilize the UDP port to multiplex results. The sequence of Domain Name Server queries dictated by an SPF script may expose the port being used. There is also a further risk that replicate queries, as possible with Bind 8 for example, may again greatly increase the chances of guessing a transaction. As this can be caused to happen repeatedly, success does not need to be 100% for this to be a concern. The two-tier recursive/non-recursive resolver was suggested as a defensive measure. It just seems more informative than recommending DNS paranoia. -Doug From owner-ietf-mxcomp@mail.imc.org Fri May 27 09:06:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08499 for ; Fri, 27 May 2005 09:06:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RChDOl055011; Fri, 27 May 2005 05:43:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RChDaw055010; Fri, 27 May 2005 05:43:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RCh9GW054980 for ; Fri, 27 May 2005 05:43:12 -0700 (PDT) (envelope-from terry@ashtonwoodshomes.com) Received: from [10.243.102.72] ([216.191.52.74]) (authenticated bits=0) by mail.greatgulfhomes.com (8.12.8/8.12.8) with ESMTP id j4RChtPB011530; Fri, 27 May 2005 08:43:55 -0400 Message-ID: <42971610.7090603@ashtonwoodshomes.com> Date: Fri, 27 May 2005 08:44:00 -0400 From: Terry Fielder User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Douglas Otis CC: julian@mehnle.net, MARID Subject: Re: draft-schlitt-spf-classic-01.txt References: <1117137745.7537.157.camel@SJC-Office-DHCP-156.mail-abuse.org> <200505262318.03899.bulk@mehnle.net> <1117166528.30777.16.camel@SJC-Office-DHCP-156.mail-abuse.org> In-Reply-To: <1117166528.30777.16.camel@SJC-Office-DHCP-156.mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Douglas Otis wrote: > On Thu, 2005-05-26 at 23:18 +0200, Julian Mehnle wrote: > >>Douglas Otis wrote: >> >> >>>The email provider must be held accountable in any meaningful approach >>>for abating abuse. However, SPF avoids such accountability. A provider >>>may feel SPF based reputation systems are of little concern to them, but >>>it should be of tremendous concern for their customers, who are often >>>little more than domain owners. >> >>Why do you think ISPs must be held accountable instead of domain owners? > > > Abating abuse requires diligence. This diligence involves the > monitoring of servers. To protect the privacy of other customers, much > of an MTA server's operation remains hidden from the domain owner, who > is often just one of many typical customers. With SPF reliance on the > mailbox-domain, the server's administrator remains anonymous. Negligent > server operation will not directly impact the administrator, but instead > impacts the domain owner. A reputation system should hold accountable > those who are expected to maintain diligence in respect to security, > access, and operation. Holding an innocent, feckless party accountable > is simply an unfair practice. Dare I say even foolish? > > By the time a domain owner is made aware that volumes of abuse has > emerged from some SPF authorized server, forging their mailbox-domain in > some unexpected header, the reputation of their domain may have become > unsuitable for email. The means to recoup their reputation in this > situation may not be practical. Interesting so if SPF fails then SPF will fail. I say this because the only way the domain owners reputation could have gotten tarnished was if either: 1) they did not implement SPF to protect forgery of their domain OR 2) they did implement SPF, and it failed to protect the forgery of their domain SPF cannot be help responsible for #1 #1 can only happen if SPF doesn't work, but if SPF doesn't work then all this is moot. Perhaps Doug, you are not talking about SPF, because "some unexpected header" sounds an awful lot like you are referring to the la-la dreamland that is PRA. And SPF is *not* PRA. Please don't confused between PRA and SPF (no matter what Meng has on the damn pobox website). > > The domain owner may be innocent. They may also view their domain as > highly valuable. They may also be required to seek expensive legal > avenues to uncover the cause of their dilemma. With SPF building upon a > filtering paradigm, there may be no outward indication their messages > are being silently dropped or placed into junk folders either. *sigh* PRA may do silent dropping of email after acceptance.. SPF does MTA time rejection, so the sending MTA *must* know that the email was undeliverable, which guarantees all real, legit connecting MTA's get a clear rejection on the delivery status. SA is the only major filtering that uses SPF after the fact, and even a FAIL scores less then 1 (0.8 something by default) and SA recommends not rejecting emails that score less than 5-10, then SPF unto itself cannot be what caused the rejection after acceptance. Something else scored the other 4-9 points that were need to cause the email to be rejected by SA! So don't say SPF causes silent dropping of email, its simply not true. Certainly not in the recommended use of SPF (MTA time rejection) and not even in the common not recommended use of SPF (SA). > It is > not clear how the domain owner will recover reliable use of their email > domain after publishing SPF and then being exploited. Domain owners can be exploited if they don't publish SPF, nothing changes by publishing SPF except, if SPF really does work (as time has shown once forwarders are fixed), SPF may prevent forgery that is the exploitation that could have resulted in bad reputation. > > This is a very real concern being completely ignored by providers > anxious to rid themselves of their responsibilities with respect to this > menacing abuse. SPF is not ignoring concerns. The concerns you have stated are either unfounded or apply to PRA, not SPF. > Nevertheless, abating abuse requires holding > administrators accountable and ensuring they stay on top of security, > access, and operational issues. Are you suggesting every MTA operator review all inbound email for forgery/spam/viruses and do something with the ones that are bad? Glad I am not paying that bill. > A reputation scheme MUST identify the > source of abuse, and not the "assumed" source of abuse. SPF is not a reputation scheme. SPF is a means to make reputation schemes accurate by preventing forgery. > A reputation > scheme must hold those responsible, accountable. SPF fails badly on > both of these issues. No, it doesn't. A reputation scheme allows domains to obtain credibility (or not) based on what the domain has done in the past. SPF simply improves the ability for reputation schemes to be accurate by preventing forgeries from affecting the reputation database. > It is folly to think SPF will improve the > integrity of email or diminish the rate of abuse. A reputation scheme > based upon SPF authorization is certain to dramatically reduce email's > integrity for the majority of domain owners. I would love to see your facts, or testing, to justify this statement. Sounds like FUD. > > > >>>Only signatures offer domain owners a modicum of control and oversight in >>>their pursuit of protecting their domain's reputation. >> >>Why? > > > By retaining a signature operation within their administrative control, > the domain owner would have far greater control over the fate of their > domain's reputation. Smells like you want to sell domain owners (or their ISP/MSP) something. A certificate perhaps? At least now I know your motivation for attacking SPF. > They could utilize the services of an email > provider to relay email from a dynamic location, without fear other > abusive messages may be confused as being from them. Thank you for endorsing the use of SPF (because that is what SPF does, only without the need for MUA upgrades to check signatures, and no need for buying certificates). > If their relay > provider was lax at security or preventing abuse, the domain owner can > seek a different provider to rectify any resulting problems. Which is a good idea no matter what security protocols one implements (or not) for their domain. Hence, thanks for the advice (albeit off topic or not specific to SPF). > > You should put yourself into your customer's position. Proclamations > that with SPF, some domain can not be forged are specious. Only when receiving MTA's don't implement SPF (or some other form of domain anti-forgery technique). But those MTA's don't matter because they won't bother to implement submission of forged emails to domain based reputation lists (or would be irresponsible if they did). > This of > course assumes closed-ended list, where the domain owner maintains > exclusive access to their servers. Please explain, because I don't understand how you could possibly think that (recall the include and redirect mechanisms). It does require that if they relay through their ISP's mail server(s) that their ISP publishes SPF, but how is that unreasonable? (No domain authentication/authorization scheme can work 100% unless it has 100% deployment, and cannot be held responsible for not working where it is not deployed) > Closed-ended lists are not > practical, nor do most domain owners manage their own MTAs with > exclusive access. Ah, so now you are talking about cross customer forgery within the same ISP. Well, either your ISP has to implement protocols to stop cross customer forgery (or be proactive about dealing with it, but I don't buy that) or we have, let's see, WE HAVE THE MESS WE ARE IN TODAY. But bottom line, the majority of forgery I doubt very much comes from the same ISP as the domain owner. (That's my experience from my log files, its someone else, often over seas, faking to be a user from my domain to see if I foolishly whitelisted by own domain name). > > A domain owner that protects the private portion of their signature, > does not depend upon an email provider to protect their reputation. Unless of course, there are other people in the world how have not implemented signature protection. Hmm, where have I heard before there could be failures if a protocol doesn't have 100% deployment? > Especially an email provider with dubious motives asking them to publish > SPF records. How on Earth can publishing an SPF record be in the > interest of the domain owner, after Microsoft proclaims server > authorization is the same as sender authentication? If you see the folly of what Microsoft is trying to do to use SPF records in ways not intended, GREAT! But that is not fault of SPF. No matter what they did, the police could not stop my neighbour from drinking and driving. Even when they impounded his car he then stole a neighbours car. Does this mean that to solve the problem the police should take cars away from everyone? No. They put the guy in jail because HE was the one that did wrong. And SPF should not be discouraged because MS is abusing it. MS should be stopped from abusing it. > > A DomainKeys signature associated with the Sender header allows the > provider to accept accountability for their customers, without mandating > their customers change their email addresses or publish DNS records. That's a great idea. Let me know when there is a free version of DomainKeys. And it works with mailing lists. And it doesn't "violate the anonymity" of email (not that I believe that email should be anonymous, but that's one of the big whines I hear against correcting forwarding). > The provider could also offer to relay messages already signed by their > customers as well. Either of these scenarios would be fair. But not free. > > With prior knowledge of the sender, perhaps in the case where an SPF > record is being used to establish a white-list, SPF could offer utility. > White-listing may be practical for typical bulk emailers, but not for > the majority of email domains. However, DomainKeys could supplant > reliance upon white-listing, without the overhead needed to maintain a > complex database that may create problematic overlaps. I hear the words but I just don't see the weight of the arguments. > > > >>>1. Introduction >>> >>>[...] >>>Unless providers can assure their customers that there are no conflicts >>>within all message PRAs, any other customer would be allowed to create >>>serious harm. >> >>If you are talking of cross-user forgery, see SPF, section 10.4[1]. This >>isn't something that can generally be solved by an authorization protocol >>that works with a granularity of IP addresses. > > > You misunderstood the concern. An email provider likely handles > customers using many different mailbox-domains. Yes, there could be > cross-user forgery within a domain, but that was not the concern. There > could also be cross-domain forgery. The provider is expected to make > assurances that some range of domains is permitted specifically for > those provided access to the MTA. If the provider does not properly > authenticate the user (some still exchange passwords in the clear), or > does not evaluate the PRA, the domain owner is placed at risk by > publishing SPF records. Uh, NO. SPF records should not be used to evaluate the PRA. > The sender does not know what the recipient > uses to base their reputation assessments. Someone can get seriously > hurt heedlessly publishing SPF. They do for receivers that correctly implement protocols (e.g. do not use SPF records for PRA). Someone could get seriously hurt if other protocols like TCP keepalives are not properly implemented. That doesn't mean we shouldn't use TCP. (repeat my drunk driving lecture here). > > > >>If you are talking of something else, I don't know what it is. >> >> >>>This harm could originate from a Zombied computer of such a customer. >>>The abuser may utilize SPF records to obfuscate where the message >>>originates to prolong their success, when seeing such messages are not >>>blocked by the sending server. >> >>How could SPF records be used to "obfuscate" a message's origin? The last >>time I looked, SPF didn't suppress the generation of "Received:" headers. > > > Anyone that utilizes a large provider and publishes an SPF record that, > in effect, proclaims such use, could enable an abuser to send from the > correct server, while still lying about who they are. SPF does not > prevent this problem. Neither does domain keys, until of course the ISP/MSP upgrades the MTA to prevent cross customer forgery. Once that is done, then EITHER method works. Amazing, if everything is done then everything works, and if only some things are done then only some things work. Fascinating. > SPF requires assumed checks that may or may not > be performed. In fact, some of these checks may require a license. : ( Huh? > > The abuser may wish to play this game until they have scorched the > reputation of that domain, before usurping the identity of the next > available victim, all while thanking SPF for making their fun possible. Ditto for any forgery method that can be circumvented. Including domainkeys. > > > >>>SPF based reputation systems could employ local or divergent databases >>>that attribute domain abuse based upon the "assumed" sender. >> >>So what? Receivers are already doing the same with IP address white- and >>black-lists. The world has not gone up in flames, though. > > > Quite typically, providers that employ a black-hole listing service, > will indicate the website of this service in the error message returned > in the session refusal. The person sending the message can opt to > immediately try a different provider to send their message. They may > also elect to complain to the black-hole listing service that indicated > the MTA they utilized is not properly administered. Email that fails authorization/authentication do not get checked/submitted to lists BECAUSE they have failed. Its only if the email passes that you then check the domain against lists. > > Perhaps the server administration permitted access to the wrong person, > perhaps they accidentally enabled an open-proxy in their network, > perhaps they even allowed an open-relay. Whatever the problem, the > sender often knows where to go for restitution. As SPF is intended to > assist the filtering of messages NO NO NO. It is to be used for MTA time rejection, not post acceptance filtering. And SA uses it for post acceptance filtering, but SPF unto itself will not cause the email to be rejected due to the incredibly low score a FAIL is assigned. > , filtering often employs a practice of > placing uncertain results into a junk folder. With SPF, there are many > shades of gray. : ( SPF is *not* PRA. Please stop the FUD. > > >>>How can the domain owner restore the use of their domain, after their >>>provider naively believes they can assume how a record will be >>>interpreted which has an undefined scope? >> >>(I assume you aren't implying that the concepts of accountability and >>reputation are fundamentally flawed.) > > > The assumption that a mailbox-domain can be authenticated without the > use of a signature is fundamentally flawed. In your opinion, especially if your opinion is to sell domainkeys. The only thing that could be considered "flawed" is that it disallows anonymous forwarding without implementing some other forwarding method (such as SRS, SES). > Server authorization is far > too weak to base a presumption of having authenticated the sender. Your argument does not hold even a drop of substance against the HELO/EHLO name checking of SPF. And it doesn't hold any credence if one (like I) don't believe in anonymous forwarding. > Server authorization in the manner of SPF also wrecks havoc on email's > architecture. There is no reason for this, when signatures require less > effort and create less collateral damage. But signatures cost more money, requires MTA's everywhere to upgrade (even those that don't WANT to participate), how is that not collateral damage? > > > >>There are no SPF records with an undefined scope. If, for v=spf1 records, >>receivers choose to apply Sender-ID's inconsistent scope definition (PRA) >>over that of SPF itself, is it SPF's fault? > > > So are you going to tell a 900 pound gorilla they are wrong? In the > end, the gorilla will have their way with you. ; ) The Open source community is a 1000 pound gorilla, once it aligns its forces. Just because some big powerful idiot is king, does not mean the kings way is right. Look through the history books, its what mutiny and revolution are all about. > > > >>Have you complained already to Microsoft and the IESG about Sender-ID >>redefining v=spf1 records? If not, why do you keep bringing up this issue >>here? To say that even though this inconsistency is not SPF's fault, >>another draft can always be employed to destroy its usefulness? > > > Strange, I see the same author on both drafts? Who's fault is that? > Depreciate the use v=spf1 to be assured of avoiding this serious > conflict. Cute. Why can't you just deploy DomainKeys, and let the best product win. Why must you resolve to attack SPF? Are you that fearful that SPF will succeed in the end that you feel a need to attack it to try to get DomainKeys deployment to catch up? > > > >>What if I submitted a draft to the IETF that conflicted with the DomainKeys >>specification? Would that make DomainKeys useless (or harmful)? > > > What patent licensing restrictions would you impose? Nothing valid. But who said the MS patent crap is valid? Its not even issued yet, just applied for. > Are you large > enough to make your claims a serious concern? You don't need to be large to apply for a patent. But your missing the point, the point was if someone applied for a patent that conflicted with domainkeys, does that make domainkeys bad? I think not. > Would you be asking > domain owners to fall into a trap, which over time as a ubiquitous > reputation program is applied, necessitates domain owners find providers > that license your scheme? Um, that sounds like PRA, not SPF. Nothing like SPF at all in fact. Interesting though, I wonder if it sounds like domainkeys? > > > > >>>10. Security Considerations >>> >>>[...] >>>With this draft mandating more than one hundred DNS lookups, >> >>The SPF specification does not "mandate more than one hundred" DNS lookups. >>It mandates that a receiver must be prepared to perform at most 111 DNS >>lookups. This does not mean that the usual case is anywhere near that. > > > Odd, but I see a required minimum as a mandate, and 111 is more than > 100. If there are on average 5 queries created for every lookup, this > could mean 555 queries are required to resolve a server's authorization > for a single message. Which would be cached. And the boundary case is likely only reached on those trying to spam or do a DOS attack. But spammers don't win, because their email is still delayed. And DOS attackers, well dealing with DOS is a fact of life no matter WHAT protocols one implements. > > > >>>this raises a concern regarding how the 20 second time limit is employed. >>>A local recursive DNS resolver may act as a UDP amplifier. Congestion >>>avoidance depends upon the application making the requests to wait, in >>>order to maintain stability. >>>[...] >> >>This sounds like a valid concern. >> >> >>>There should also be a warning about acceptance of duplicate records. >> >>What do you mean by "duplicate records"? > > > DNS transactions are only protected by a 16 bit integer. Often routines > utilize the UDP port to multiplex results. The sequence of Domain Name > Server queries dictated by an SPF script may expose the port being used. > There is also a further risk that replicate queries, as possible with > Bind 8 for example, may again greatly increase the chances of guessing a > transaction. As this can be caused to happen repeatedly, success does > not need to be 100% for this to be a concern. The two-tier > recursive/non-recursive resolver was suggested as a defensive measure. > It just seems more informative than recommending DNS paranoia. > Agreed. IF one is using a DNS service with known vulnerabilities and IF this and IF that THEN, well, you deserve to be vulnerable, don't you? Terry > > -Doug > > -- Terry Fielder terry@greatgulfhomes.com Associate Director Software Development and Deployment Great Gulf Homes / Ashton Woods Homes Fax: (416) 441-9085 From owner-ietf-mxcomp@mail.imc.org Fri May 27 18:03:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08251 for ; Fri, 27 May 2005 18:03:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RLavKI071956; Fri, 27 May 2005 14:36:57 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RLavKn071955; Fri, 27 May 2005 14:36:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RLasRj071945 for ; Fri, 27 May 2005 14:36:54 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id E9421414F0; Fri, 27 May 2005 14:36:48 -0700 (PDT) Subject: Re: draft-schlitt-spf-classic-01.txt From: Douglas Otis To: Terry Fielder Cc: julian@mehnle.net, MARID In-Reply-To: <42971610.7090603@ashtonwoodshomes.com> References: <1117137745.7537.157.camel@SJC-Office-DHCP-156.mail-abuse.org> <200505262318.03899.bulk@mehnle.net> <1117166528.30777.16.camel@SJC-Office-DHCP-156.mail-abuse.org> <42971610.7090603@ashtonwoodshomes.com> Content-Type: text/plain Date: Fri, 27 May 2005 14:36:45 -0700 Message-Id: <1117229806.10255.266.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2005-05-27 at 08:44 -0400, Terry Fielder wrote: > Douglas Otis wrote: > > On Thu, 2005-05-26 at 23:18 +0200, Julian Mehnle wrote: > > > > Abating abuse requires diligence. This diligence involves the > > monitoring of servers. To protect the privacy of other customers, much > > of an MTA server's operation remains hidden from the domain owner, who > > is often just one of many typical customers. With SPF reliance on the > > mailbox-domain, the server's administrator remains anonymous. Negligent > > server operation will not directly impact the administrator, but instead > > impacts the domain owner. A reputation system should hold accountable > > those who are expected to maintain diligence in respect to security, > > access, and operation. Holding an innocent, feckless party accountable > > is simply an unfair practice. Dare I say even foolish? > > > > By the time a domain owner is made aware that volumes of abuse has > > emerged from some SPF authorized server, forging their mailbox-domain in > > some unexpected header, the reputation of their domain may have become > > unsuitable for email. The means to recoup their reputation in this > > situation may not be practical. > > Interesting so if SPF fails then SPF will fail. > > I say this because the only way the domain owners reputation could have > gotten tarnished was if either: > > 1) they did not implement SPF to protect forgery of their domain Publishing SPF, even offering low levels of "server authorization," is mistakenly viewed by some as "sender authentication" of the domain. Publishing SPF provides these recipients with what they believe to be confirmations, albeit flimsy, that your domain has actually sent the message. Publishing any SPF record unfortunately exposes your domain to these widely promoted, but contemptibly false assumptions. Not offering this damning confirmation is the only sure means to avoid being assessed in this manner. Rather than being incensed and reckless by publishing SPF records, when weary of the spoofs and thinking SPF is your salvation against this sea of troubles, consider your options carefully. Know your exposures. SPF and abusers together pose very serious threats. > 2) they did implement SPF, and it failed to protect the forgery of > their domain You have again assumed the domain owner publishing SPF is in a position to wage a defense against the forgery of their domain. SPF places this duty onto the faceless email provider, who remains unscathed by their acts of negligence. They may even claim proprietary checks are outside their bailiwick, although it then offers an avenue for the forger to impugn your reputation. > SPF cannot be help responsible for #1 There are some providers that wish to force use of SPF, and there lies the rub. > #1 can only happen if SPF doesn't work, but if SPF doesn't work then all > this is moot. > > Perhaps Doug, you are not talking about SPF, because "some unexpected > header" sounds an awful lot like you are referring to the la-la > dreamland that is PRA. > > And SPF is *not* PRA. Please don't confused between PRA and SPF (no > matter what Meng has on the damn pobox website). Millions of users soon will be running an application that will accrue "user feedback" against the Purported Responsible Address algorithm confirmed with the v=spf1 record, as widely promoted. You would be rather foolish to ignore this. As an expert, you would be negligent advising anyone to publish an v=spf1 record, and not insist they also require PRA conflict protections. The first question a wary domain owner would need to ask, "Do you enforce the PRA for all of your customers?" How is it that the same author appears on these two drafts, and yet this conflict is not taken far more seriously? Offering advice to ignore Sender-ID would be outright laughable, if it were not so serious. How will you indemnify your customers from such negligence? > > The domain owner may be innocent. They may also view their domain as > > highly valuable. They may also be required to seek expensive legal > > avenues to uncover the cause of their dilemma. With SPF building upon a > > filtering paradigm, there may be no outward indication their messages > > are being silently dropped or placed into junk folders either. > > *sigh* > > PRA may do silent dropping of email after acceptance.. > > SPF does MTA time rejection, so the sending MTA *must* know that the > email was undeliverable, which guarantees all real, legit connecting > MTA's get a clear rejection on the delivery status. > > SA is the only major filtering that uses SPF after the fact, and even a > FAIL scores less then 1 (0.8 something by default) and SA recommends not > rejecting emails that score less than 5-10, then SPF unto itself cannot > be what caused the rejection after acceptance. Something else scored > the other 4-9 points that were need to cause the email to be rejected by SA! > > So don't say SPF causes silent dropping of email, its simply not true. > Certainly not in the recommended use of SPF (MTA time rejection) and not > even in the common not recommended use of SPF (SA). Yes, the PRA may make this much worse. What happens at the back-end, when the PRA algorithm is a plug-in for Outlook? Now you have both wonderfully weak algorithms being applied to your domain, all thanks to SPF. You need to strongly advise against the use of v=spf1. It must go! Don't publish v=spf1 records, and if you have published them, they need to be removed, or at least replaced with a different version that includes scope. When used for white-listing, the scope "ADMIN" could be used. : ) > > It is not clear how the domain owner will recover reliable use of > > their email domain after publishing SPF and then being exploited. > > Domain owners can be exploited if they don't publish SPF, nothing > changes by publishing SPF except, if SPF really does work (as time has > shown once forwarders are fixed), SPF may prevent forgery that is the > exploitation that could have resulted in bad reputation. What do you mean the domain owner's reputation can still be exploited? What type of reputation system would base abuse assessments upon totally unconfirmed identifiers? Hopefully, the only confirmed identifiers, such as the MTA IP address, would then be used. It would be incredible to have a domain assessed for not publishing an SPF record. I would even commend them! Ask that their MTA properly confirm their HELO, that they use S/MIME, DomainKeys, or any other strong method that identifies the source of the message. SPF's weak and broken authorization scheme will wreck havoc on email's delivery integrity. > > This is a very real concern being completely ignored by providers > > anxious to rid themselves of their responsibilities with respect to this > > menacing abuse. > > SPF is not ignoring concerns. The concerns you have stated are either > unfounded or apply to PRA, not SPF. Both SPF and Sender-ID ignore the identity of the server administrator. Both SPF and Sender-ID premise all assessment upon the domain-owner, where the server administrator _never_ enters into consideration. > > Nevertheless, abating abuse requires holding administrators > > accountable and ensuring they stay on top of security, access, > > and operational issues. > > Are you suggesting every MTA operator review all inbound email for > forgery/spam/viruses and do something with the ones that are bad? Glad > I am not paying that bill. I am suggesting the MTA administrator is the _only_ one that can respond when there is a security problem, or inappropriate access is being granted. The MTA administrator should monitor all outbound logs and watch for excessive errors, or unusual levels of outbound email. They also need to investigate abuse reports of their outbound email. None of these duties can be expected of the domain owner. The domain owner has scant few tools to even know when there is a problem, and even fewer for correcting the situation. The MTA administrator has many tools and can respond. > > A reputation scheme MUST identify the source of abuse, and not the > > "assumed" source of abuse. > > SPF is not a reputation scheme. > > SPF is a means to make reputation schemes accurate by preventing forgery. SPF will not prevent forgery in most cases. In those cases where forgery still occurs, disaster! SPF will change forgery from a nuisance (remedied with bounce address tag validation), into a total meltdown of the domain. You really need to avoid making specious claims about what SPF may accomplish, without also considering what it may not accomplish. > > A reputation scheme must hold those responsible, accountable. SPF > > fails badly on both of these issues. > > No, it doesn't. A reputation scheme allows domains to obtain > credibility (or not) based on what the domain has done in the past. Do you really consider SPF is a means to authenticate the sender? What assumptions are involved when arriving at that conclusion? This is why SPF is so dangerous. > SPF simply improves the ability for reputation schemes to be accurate by > preventing forgeries from affecting the reputation database. Publishing SPF does not prevent forgeries. Many other protections must be instantiated, where any missing element in this phalanx of required protections permits forgery. SPF may even invite forgery. (Even assuming it was practical to impose strict authorization to maintain this claim.) In the typical case, the domain owner will likely be blithely unaware of the essential elements needed to guard their reputation. You have already declared that you will permit PRA forgery, as in your view, this is not your concern. SPF only offers server authorization. It would be foolish to call this a forgery prevention scheme, as likely anyone with access to the same server may be able to forge messages from a domain that authorizes the server with SPF. These SPF records are public, so the abuser will not be guessing who they can impersonate. : ( > > It is folly to think SPF will improve the integrity of email or > > diminish the rate of abuse. A reputation scheme based upon SPF > > authorization is certain to dramatically reduce email's integrity > > for the majority of domain owners. > > I would love to see your facts, or testing, to justify this statement. > Sounds like FUD. Yes, I heard that speech several times. I would strongly advise you to consider strong identifiers that can be defended. A domain owner would be incredibly foolish to place their domain's reputation into the hands of an email provider that scoffs at monitoring their server as being too expensive. While SPF may permit providers a "What, me worry?" attitude, it will be the consumer that will pay dearly. > > By retaining a signature operation within their administrative control, > > the domain owner would have far greater control over the fate of their > > domain's reputation. > > Smells like you want to sell domain owners (or their ISP/MSP) something. > A certificate perhaps? At least now I know your motivation for > attacking SPF. Boy are you barking up the wrong tree. Turn around, I think someone wants to see your license. : ) > > They could utilize the services of an email provider to relay email > > from a dynamic location, without fear other abusive messages may be > > confused as being from them. > > Thank you for endorsing the use of SPF (because that is what SPF does, > only without the need for MUA upgrades to check signatures, and no need > for buying certificates). You do not need to buy certificates for either DomainKeys or Identified Internet Mail. I have no financial incentive for recommending either of these proposals being consider ahead of SPF, other than a desire to see email remain a viable means to openly exchange information. SPF does not offer a fig leaf of protection. You assume the email provider, who ensures access to the server, also limits what is sent through the server. In the age of Zombied computers everywhere, expect anyone with access will try anything. Your only protection with SPF depends upon a poorly defined set of assurances that must be made by a dubiously diligent provider. They may believe as you do, that SPF is its own protection. After all, it would not be their reputation damaged would it? > > If their relay provider was lax at security or preventing abuse, the > > domain owner can seek a different provider to rectify any resulting > > problems. > > Which is a good idea no matter what security protocols one implements > (or not) for their domain. Hence, thanks for the advice (albeit off > topic or not specific to SPF). Somehow considering the alternative does seem on topic. > > You should put yourself into your customer's position. Proclamations > > that with SPF, some domain can not be forged are specious. > > Only when receiving MTA's don't implement SPF (or some other form of > domain anti-forgery technique). But those MTA's don't matter because > they won't bother to implement submission of forged emails to domain > based reputation lists (or would be irresponsible if they did). You have made the point as to why there are advantages avoiding the publishing of SPF. > > This of course assumes closed-ended list, where the domain owner > > maintains exclusive access to their servers. > > Please explain, because I don't understand how you could possibly think > that (recall the include and redirect mechanisms). > > It does require that if they relay through their ISP's mail server(s) > that their ISP publishes SPF, but how is that unreasonable? (No domain > authentication/authorization scheme can work 100% unless it has 100% > deployment, and cannot be held responsible for not working where it is > not deployed) It remains impossible to list servers of those recipients that forward their email, for example. While I have seen it argued this problem is now the fault of the recipient, it still results in the loss of messages. The remedy is to offer a lowered level of server authorization, at the expense of being forged at this level. > > Closed-ended lists are not practical, nor do most domain owners > > manage their own MTAs with exclusive access. > > Ah, so now you are talking about cross customer forgery within the same > ISP. Well, either your ISP has to implement protocols to stop cross > customer forgery (or be proactive about dealing with it, but I don't buy > that) or we have, let's see, WE HAVE THE MESS WE ARE IN TODAY. But that mess will not impact your domain's reputation, unless you are silly enough to offer SPF server authorization construed to be "sender authentication." > But bottom line, the majority of forgery I doubt very much comes from > the same ISP as the domain owner. (That's my experience from my log > files, its someone else, often over seas, faking to be a user from my > domain to see if I foolishly white-listed by own domain name). It is futile to go after today's behavior without considering how that behavior may change. Is it any wonder those promoting SPF don't want to talk directly about these concerns, and instead treat their audience like a bunch of patsies ready to believe anything? "Don't listen to anyone raising concerns about SPF/Sender-ID, they're just trying to spread FUD!" I have heard this speech several times already. I wonder if I should take this as a personal attack. ; ) > > A domain owner that protects the private portion of their signature, > > does not depend upon an email provider to protect their reputation. > > Unless of course, there are other people in the world how have not > implemented signature protection. Hmm, where have I heard before there > could be failures if a protocol doesn't have 100% deployment? The signature can be ignored by the recipient without harm. It only requires the sender to implement a signature scheme. They then do not need any protective cooperation by every down stream server, as does SPF/Sender-ID. > > Especially an email provider with dubious motives asking them to publish > > SPF records. How on Earth can publishing an SPF record be in the > > interest of the domain owner, after Microsoft proclaims server > > authorization is the same as sender authentication? > > If you see the folly of what Microsoft is trying to do to use SPF > records in ways not intended, GREAT! But that is not fault of SPF. > > No matter what they did, the police could not stop my neighbor from > drinking and driving. Even when they impounded his car he then stole a > neighbors car. Does this mean that to solve the problem the police > should take cars away from everyone? No. They put the guy in jail > because HE was the one that did wrong. > > And SPF should not be discouraged because MS is abusing it. MS should > be stopped from abusing it. How can you say Microsoft is wrong, and an SPF cabal is right? Again, both drafts even share the same author. Why blame anyone for there not being any definition on the scope of the SPF record. Depreciate v=spf1, advise its removal, and get on with life. > > A DomainKeys signature associated with the Sender header allows the > > provider to accept accountability for their customers, without mandating > > their customers change their email addresses or publish DNS records. > > That's a great idea. Let me know when there is a free version of > DomainKeys. And it works with mailing lists. And it doesn't "violate > the anonymity" of email (not that I believe that email should be > anonymous, but that's one of the big whines I hear against correcting > forwarding). Yes, there is a free version: http://domainkeys.sourceforge.net/ > > The provider could also offer to relay messages already signed by their > > customers as well. Either of these scenarios would be fair. > > But not free. Yes, free! > > You misunderstood the concern. An email provider likely handles > > customers using many different mailbox-domains. Yes, there could be > > cross-user forgery within a domain, but that was not the concern. There > > could also be cross-domain forgery. The provider is expected to make > > assurances that some range of domains is permitted specifically for > > those provided access to the MTA. If the provider does not properly > > authenticate the user (some still exchange passwords in the clear), or > > does not evaluate the PRA, the domain owner is placed at risk by > > publishing SPF records. > > Uh, NO. SPF records should not be used to evaluate the PRA. Tell that to Microsoft. Let me know how that goes. : ) > > The sender does not know what the recipient uses to base their > > reputation assessments. Someone can get seriously hurt heedlessly > > publishing SPF. > > They do for receivers that correctly implement protocols (e.g. do not > use SPF records for PRA). > > Someone could get seriously hurt if other protocols like TCP keepalives > are not properly implemented. That doesn't mean we shouldn't use TCP. > (repeat my drunk driving lecture here). What makes any SPF cabal the protocol authority? The SPF record did not have a defined scope, where a scope was added when it became apparent Sender-ID would attempt to use the same silly path registration scheme. Microsoft claims their algorithm breaks less often and see their claim equally valid, their view of scope should prevail. > > Anyone that utilizes a large provider and publishes an SPF record that, > > in effect, proclaims such use, could enable an abuser to send from the > > correct server, while still lying about who they are. SPF does not > > prevent this problem. > > Neither does domain keys, until of course the ISP/MSP upgrades the MTA > to prevent cross customer forgery. Once that is done, then EITHER > method works. Amazing, if everything is done then everything works, and > if only some things are done then only some things work. Fascinating. Sender-ID and SPF depend upon universal checks at each public MTA. Signatures schemes only requires a sender implementation. > > SPF requires assumed checks that may or may not be performed. In > > fact, some of these checks may require a license. : ( > > Huh? Yes, the PRA you wish would go away. Its back... > > The abuser may wish to play this game until they have scorched the > > reputation of that domain, before usurping the identity of the next > > available victim, all while thanking SPF for making their fun possible. > > Ditto for any forgery method that can be circumvented. Including > domainkeys. While forging a message with SPF only requires access to any authorized server (not even to the SMTP application), and the forgeries can commence. That can not be said of DomainKeys. > > Perhaps the server administration permitted access to the wrong person, > > perhaps they accidentally enabled an open-proxy in their network, > > perhaps they even allowed an open-relay. Whatever the problem, the > > sender often knows where to go for restitution. As SPF is intended to > > assist the filtering of messages > > NO NO NO. It is to be used for MTA time rejection, not post acceptance > filtering. And SA uses it for post acceptance filtering, but SPF unto > itself will not cause the email to be rejected due to the incredibly low > score a FAIL is assigned. You mean no one will ever receive a bad reputation based upon SPF server authorization? The concern was what happens when they do. > > , filtering often employs a practice of > > placing uncertain results into a junk folder. With SPF, there are many > > shades of gray. : ( > > SPF is *not* PRA. Please stop the FUD. This problem is valid in both cases, and yes worse with PRA. Please stop attempting to disavow Sender-IDs use of the v=spf1 record. I suggest if anyone needs to be consulted, you should query the author of both drafts. > > The assumption that a mailbox-domain can be authenticated without the > > use of a signature is fundamentally flawed. > > In your opinion, especially if your opinion is to sell domainkeys. The > only thing that could be considered "flawed" is that it disallows > anonymous forwarding without implementing some other forwarding method > (such as SRS, SES). > > > Server authorization is far > > too weak to base a presumption of having authenticated the sender. > > Your argument does not hold even a drop of substance against the > HELO/EHLO name checking of SPF. You don't really expect anyone to care about the HELO do you? As far as SPF is concerned, it is there when the message is a DSN. CSV offers much lower overhead for this check anyway. I suspect it will come into consideration once signatures are prevalent, and then the need will be more readily perceived. > And it doesn't hold any credence if one (like I) don't believe in > anonymous forwarding. Thought so, but then you don't care about who is administering the server. > > Server authorization in the manner of SPF also wrecks havoc on email's > > architecture. There is no reason for this, when signatures require less > > effort and create less collateral damage. > > But signatures cost more money, requires MTA's everywhere to upgrade > (even those that don't WANT to participate), how is that not collateral > damage? These are myths at this point. The overhead required affects the CPU on the mail server that has adequate margins to permit signatures without upgrading equipment. Signatures offer less overhead. They even represent less impact that SPF/Sender-ID. > > So are you going to tell a 900 pound gorilla they are wrong? In the > > end, the gorilla will have their way with you. ; ) > > The Open source community is a 1000 pound gorilla, once it aligns its > forces. Just because some big powerful idiot is king, does not mean the > kings way is right. Look through the history books, its what mutiny and > revolution are all about. In some areas perhaps. I am 100% behind the open source effort. But be serious, Microsoft controls too many desktops at this time to be ignored. You do so, only at your peril. > > Strange, I see the same author on both drafts? Who's fault is that? > > Depreciate the use v=spf1 to be assured of avoiding this serious > > conflict. > > Cute. Why can't you just deploy DomainKeys, and let the best product > win. Why must you resolve to attack SPF? Are you that fearful that SPF > will succeed in the end that you feel a need to attack it to try to get > DomainKeys deployment to catch up? I am pointing out what I see is still VERY wrong the SPF draft. I am placing my comments here because I think SPF, when used in the manner advocated, place the email community at risk. I would rather provide a REAL means for people to publish a record that says I DO NOT ASSURE THE PRA IDENTITY, without that becoming a liability. The way it is currently defined, SPF is little more than a trap. -Doug From owner-ietf-mxcomp@mail.imc.org Fri May 27 18:43:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11918 for ; Fri, 27 May 2005 18:43:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RMOOxC086714; Fri, 27 May 2005 15:24:24 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4RMOOBD086713; Fri, 27 May 2005 15:24:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4RMONRq086706 for ; Fri, 27 May 2005 15:24:24 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id D5BF416D00 for ; Fri, 27 May 2005 18:22:41 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt In-Reply-To: Your message of "Fri, 27 May 2005 14:36:45 PDT." <1117229806.10255.266.camel@SJC-Office-DHCP-156.mail-abuse.org> Date: Fri, 27 May 2005 18:22:41 -0400 Message-Id: <20050527222241.D5BF416D00@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis wrote: > Publishing SPF, even offering low levels of "server authorization," is > mistakenly viewed by some as "sender authentication" of the domain. > Publishing SPF provides these recipients with what they believe to be > confirmations, albeit flimsy, that your domain has actually sent the > message. Publishing any SPF record unfortunately exposes your domain to > these widely promoted, but contemptibly false assumptions. Let's correct the false assumptions then, rather than throwing out the proposal. Many people believe putting their computer on the net is OK. When they get viruses, the answer isn't to ban the net, it's to fix their beliefs. > Not offering this damning confirmation is the only sure means to avoid > being assessed in this manner. Not giving people tools is the best way to ensure they won't hurt themselves. I find it curious that there's opposition to a "harmful" proposal like SPF, but the "harmful" practice of sending unauthenticated email from anywhere on the net is called "roaming", and is deemed to be a requirement of SMTP. Weird. All I know is that SPF has harmed me a lot less than "roaming" has. The endless dribbles of email from clueless people to "postmaster" or "webmaster" claiming that my domain has spammed them is tiring. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Fri May 27 20:32:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17579 for ; Fri, 27 May 2005 20:32:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4S0AVf6007201; Fri, 27 May 2005 17:10:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4S0AVlh007200; Fri, 27 May 2005 17:10:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4S0ASPS007056 for ; Fri, 27 May 2005 17:10:28 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id 74EC9414F1; Fri, 27 May 2005 17:10:23 -0700 (PDT) Subject: Re: draft-schlitt-spf-classic-01.txt From: Douglas Otis To: Alan DeKok Cc: ietf-mxcomp@imc.org In-Reply-To: <20050527222241.D5BF416D00@mail.nitros9.org> References: <20050527222241.D5BF416D00@mail.nitros9.org> Content-Type: text/plain Date: Fri, 27 May 2005 17:10:22 -0700 Message-Id: <1117239023.22042.61.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2005-05-27 at 18:22 -0400, Alan DeKok wrote: > Douglas Otis wrote: > > Publishing SPF, even offering low levels of "server authorization," is > > mistakenly viewed by some as "sender authentication" of the domain. > > Publishing SPF provides these recipients with what they believe to be > > confirmations, albeit flimsy, that your domain has actually sent the > > message. Publishing any SPF record unfortunately exposes your domain to > > these widely promoted, but contemptibly false assumptions. > > Let's correct the false assumptions then, rather than throwing out > the proposal. Many people believe putting their computer on the net > is OK. When they get viruses, the answer isn't to ban the net, it's > to fix their beliefs. One major assumption needing corrected is the assumed scope implied by an v=spf1 record. There are vendors able to exercise significant influence with respect to their view of the scope implied by this record. You have another group that feels they can declare a default scope, in a manner they consider appropriate, albeit in conflict. Those holding the Presumed is better than Purported need to recognize they will not prevail. A reasonable means to extricate the draft from this situation would be to depreciate the use of v=spf1, advise its removals, and then document a new spf2 scope. Even define a scope like "ADMIN", that indicates there are _no_ assurances being made within mail stream regarding any identifier. It would simply be used to indicate addresses being administered by a particular domain. One could say "To ensure this administrative domain does not accidentally get blocked, apply this to your white-list." > > Not offering this damning confirmation is the only sure means to avoid > > being assessed in this manner. > > Not giving people tools is the best way to ensure they won't hurt > themselves. > > > I find it curious that there's opposition to a "harmful" proposal > like SPF, but the "harmful" practice of sending unauthenticated email > from anywhere on the net is called "roaming", and is deemed to be a > requirement of SMTP. I would not hand a child a circular saw, and then say don't worry about pulling this trigger. SPF is handing a dangerous tool to the domain owner without advising them of the serious risks they assume when publishing. I find that outrageous. I am not against authenticating the source of email. The use of SPF does not authenticate the sender, it only provides "server authorization" which is being construed as being "sender authentication." There are valid alternatives that I would happily endorse, such as DomainKeys, or even CSV. A mailbox-domain assertion depends on too many assumptions to ever be safe as an identifier serving as a basis for reputation. > Weird. As difficult as dealing with IP addresses are, they represent a stronger identifier when logged against repeated events of abuse. They also more directly impact the administrator. If there is an open-proxy or address spoofing situation, perhaps assisted by way of a tunnel, they need to squelch that problem. I too would like to see authentication move into the name space. As I said, DomainKeys or CSV provides both safe and fair names that can be authenticated. These identifiers can be defended, and do not put the average consumer at risk of seeing their domain's utility being destroyed by a negligent provider. Yes, providers will be required to remain vigilant, unlike that suggested by some SPF proponents. > All I know is that SPF has harmed me a lot less than "roaming" has. > The endless dribbles of email from clueless people to "postmaster" or > "webmaster" claiming that my domain has spammed them is tiring. I offered suggestions that a domain assertion could be added to the CSV record that indicates all of a domain's emails are signed. This would be a lightweight, single lookup extension that could allow any domain a means to identify any message that purports to be from your domain, but then must validate their signature. There are other issues related to signatures where this would be a useful tool. I describe this at: http://www.kelkea.com/ietf/draft-otis-mass-reputation-01.html -Doug From owner-ietf-mxcomp@mail.imc.org Fri May 27 20:52:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18813 for ; Fri, 27 May 2005 20:52:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4S0VJMX026916; Fri, 27 May 2005 17:31:19 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4S0VJI1026915; Fri, 27 May 2005 17:31:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.nitros9.org (newgiles.striker.ottawa.on.ca [205.150.200.131]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4S0VJx2026890 for ; Fri, 27 May 2005 17:31:19 -0700 (PDT) (envelope-from aland@nitros9.org) Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 8BCCC16FAB for ; Fri, 27 May 2005 20:29:42 -0400 (EDT) From: "Alan DeKok" To: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt In-Reply-To: Your message of "Fri, 27 May 2005 17:10:22 PDT." <1117239023.22042.61.camel@SJC-Office-DHCP-156.mail-abuse.org> Date: Fri, 27 May 2005 20:29:42 -0400 Message-Id: <20050528002942.8BCCC16FAB@mail.nitros9.org> Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis wrote: > One major assumption needing corrected is the assumed scope implied by > an v=spf1 record. There are vendors able to exercise significant > influence with respect to their view of the scope implied by this > record. You have another group that feels they can declare a default > scope, in a manner they consider appropriate, albeit in conflict. This is a political issue, and not a flaw in the technical proposal. > SPF is handing a dangerous tool to the domain owner without advising > them of the serious risks they assume when publishing. I find that > outrageous. As you've said. The proponents have disagreed, and "never the twain shall meet." > I offered suggestions that a domain assertion could be added to the CSV > record that indicates all of a domain's emails are signed. Which is a great idea. Alan DeKok. From owner-ietf-mxcomp@mail.imc.org Fri May 27 22:31:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24204 for ; Fri, 27 May 2005 22:31:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4S26iGZ057830; Fri, 27 May 2005 19:06:44 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4S26ifb057829; Fri, 27 May 2005 19:06:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.greatgulfhomes.com (mail.greatgulfhomes.com [216.191.52.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4S26g9L057822 for ; Fri, 27 May 2005 19:06:43 -0700 (PDT) (envelope-from terry@ashtonwoodshomes.com) Received: from [10.243.102.72] ([216.191.52.74]) (authenticated bits=0) by mail.greatgulfhomes.com (8.12.8/8.12.8) with ESMTP id j4S27UPB021972; Fri, 27 May 2005 22:07:30 -0400 Message-ID: <4297D265.3030307@ashtonwoodshomes.com> Date: Fri, 27 May 2005 22:07:33 -0400 From: Terry Fielder User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Douglas Otis CC: julian@mehnle.net, MARID Subject: Re: draft-schlitt-spf-classic-01.txt References: <1117137745.7537.157.camel@SJC-Office-DHCP-156.mail-abuse.org> <200505262318.03899.bulk@mehnle.net> <1117166528.30777.16.camel@SJC-Office-DHCP-156.mail-abuse.org> <42971610.7090603@ashtonwoodshomes.com> <1117229806.10255.266.camel@SJC-Office-DHCP-156.mail-abuse.org> In-Reply-To: <1117229806.10255.266.camel@SJC-Office-DHCP-156.mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Douglas Otis wrote: > On Fri, 2005-05-27 at 08:44 -0400, Terry Fielder wrote: > >>Douglas Otis wrote: >> >>>On Thu, 2005-05-26 at 23:18 +0200, Julian Mehnle wrote: >>> >>>Abating abuse requires diligence. This diligence involves the >>>monitoring of servers. To protect the privacy of other customers, much >>>of an MTA server's operation remains hidden from the domain owner, who >>>is often just one of many typical customers. With SPF reliance on the >>>mailbox-domain, the server's administrator remains anonymous. Negligent >>>server operation will not directly impact the administrator, but instead >>>impacts the domain owner. A reputation system should hold accountable >>>those who are expected to maintain diligence in respect to security, >>>access, and operation. Holding an innocent, feckless party accountable >>>is simply an unfair practice. Dare I say even foolish? >>> >>>By the time a domain owner is made aware that volumes of abuse has >>>emerged from some SPF authorized server, forging their mailbox-domain in >>>some unexpected header, the reputation of their domain may have become >>>unsuitable for email. The means to recoup their reputation in this >>>situation may not be practical. >> >>Interesting so if SPF fails then SPF will fail. >> >>I say this because the only way the domain owners reputation could have >>gotten tarnished was if either: >> >>1) they did not implement SPF to protect forgery of their domain > > > Publishing SPF, even offering low levels of "server authorization," is > mistakenly viewed by some as "sender authentication" of the domain. Agreed, educate the masses. But good luck, because there are a lot of computer users without the faintest clue of how things work. Hence why phishing is so effective. > Publishing SPF provides these recipients with what they believe to be > confirmations, albeit flimsy, that your domain has actually sent the > message. I doubt most users have a clue what SPF means. Or domainkeys. Or PRA. > Publishing any SPF record unfortunately exposes your domain to > these widely promoted, but contemptibly false assumptions. Yes, along with the false assumption that domainkeys is the FUSSP. > > Not offering this damning confirmation is the only sure means to avoid > being assessed in this manner. What confirmation??? The users don't see a little lock symbol which they can misinterpret to see as secure. They simply don't see messages that were rejected at the MTA. > Rather than being incensed and reckless > by publishing SPF records, when weary of the spoofs and thinking SPF is > your salvation against this sea of troubles, consider your options > carefully. Know your exposures. SPF and abusers together pose very > serious threats. SPF does not present the problem, abusers do. But abusers find loopholes in all methods. If they didn't, then we would already have the FUSSP. > > > >>2) they did implement SPF, and it failed to protect the forgery of >>their domain > > > You have again assumed the domain owner publishing SPF is in a position > to wage a defense against the forgery of their domain. Um, they waged the defense by publishing SPF knowing that means MTA's that check SPF will reject the forgery of their domain. That *is* waging the defense. > SPF places this > duty onto the faceless email provider, who remains unscathed by their > acts of negligence. "Act of negligence": Clearly you see SPF as a threat to your product. Go promote DomainKeys by showing what it has to offer, rather then trying to raise false and unsubstantiated claims against the competition. > They may even claim proprietary checks are outside > their bailiwick, although it then offers an avenue for the forger to > impugn your reputation. SPF is not proprietary. SPF is not PRA. PRA is proprietary. And where does domainkeys lie? Free? Open source? > > > >>SPF cannot be help responsible for #1 > > > There are some providers that wish to force use of SPF, and there lies > the rub. When they do, its relevant for all I have seen, because said providers are the domain DNS hoster and MSP for the domain, so they know where the emails will come from. And if someone wants their SPF record to be enhanced to include other MSP or IP's etc, I am sure they can. If the domain providers pushing SPF were so bad, and were doing their customers so bad, they wouldn't have any customers left: This is a free society and the masses will take their money and business where they want to. > > > >>#1 can only happen if SPF doesn't work, but if SPF doesn't work then all >>this is moot. >> >>Perhaps Doug, you are not talking about SPF, because "some unexpected >>header" sounds an awful lot like you are referring to the la-la >>dreamland that is PRA. >> >>And SPF is *not* PRA. Please don't confused between PRA and SPF (no >>matter what Meng has on the damn pobox website). > > > Millions of users soon will be running an application that will accrue > "user feedback" against the Purported Responsible Address algorithm > confirmed with the v=spf1 record, as widely promoted. You would be > rather foolish to ignore this. I do not ignore it. I am very prepared to advise everyone to disable the PRA when the latest version of exchange/whatever comes out. (Course I also advise everyone to get rid of M$ Exchange) > As an expert, you would be negligent > advising anyone to publish an v=spf1 record, and not insist they also > require PRA conflict protections. The first question a wary domain > owner would need to ask, "Do you enforce the PRA for all of your > customers?" Don't need to, PRA should not be scooping SPFv1 records, they are proven incompatible. PRA should use their own SPF2.0 records. Don't blame SPF because PRA is doing something bad, blame PRA. And domain owners have a defense against the PRA, publish the counter PRA record: "spf2.0/pra ?all" so PRA does not misinterpret the SPF as a PRA data. > > How is it that the same author appears on these two drafts, and yet this > conflict is not taken far more seriously? I don't pretend to understand or care to understand who was underhanded or bought or ulteriorly motivated that ended MARID up where it got. It doesn't matter. > Offering advice to ignore > Sender-ID would be outright laughable, if it were not so serious. How > will you indemnify your customers from such negligence? > I advise everyone of the need to ensure PRA is disabled, and if there are concerns that others they communicate with do not disable PRA then they should publish the SPF2.0 record: spf2.0/pra ?all > > >>>The domain owner may be innocent. They may also view their domain as >>>highly valuable. They may also be required to seek expensive legal >>>avenues to uncover the cause of their dilemma. With SPF building upon a >>>filtering paradigm, there may be no outward indication their messages >>>are being silently dropped or placed into junk folders either. >> >>*sigh* >> >>PRA may do silent dropping of email after acceptance.. >> >>SPF does MTA time rejection, so the sending MTA *must* know that the >>email was undeliverable, which guarantees all real, legit connecting >>MTA's get a clear rejection on the delivery status. >> >>SA is the only major filtering that uses SPF after the fact, and even a >>FAIL scores less then 1 (0.8 something by default) and SA recommends not >>rejecting emails that score less than 5-10, then SPF unto itself cannot >>be what caused the rejection after acceptance. Something else scored >>the other 4-9 points that were need to cause the email to be rejected by SA! >> >>So don't say SPF causes silent dropping of email, its simply not true. >>Certainly not in the recommended use of SPF (MTA time rejection) and not >>even in the common not recommended use of SPF (SA). > > > Yes, the PRA may make this much worse. What happens at the back-end, > when the PRA algorithm is a plug-in for Outlook? Umm, MTA checking algorithm's should *never* be applied at the MUA, because its too late to do an MTA reject. Don't blame SPF because PRA is bad. You keep successfully arguing against PRA, thanks for being on the SPF side. Too bad you cannot find any legitmate arguments against SPF. > Now you have both > wonderfully weak algorithms being applied to your domain, all thanks to > SPF. No, the wonderfully weak algorithm is because PRA is abusing SPFv1 records. Move on. > You need to strongly advise against the use of v=spf1. It must > go! Don't publish v=spf1 records, and if you have published them, they > need to be removed, or at least replaced with a different version that > includes scope. When used for white-listing, the scope "ADMIN" could be > used. : ) No, publish SPF. And if someone actually is stupid enough to deploy/enable PRA, then publish the anti-pra record: spf2.0/pra ?all > > > >>>It is not clear how the domain owner will recover reliable use of >>>their email domain after publishing SPF and then being exploited. >> >>Domain owners can be exploited if they don't publish SPF, nothing >>changes by publishing SPF except, if SPF really does work (as time has >>shown once forwarders are fixed), SPF may prevent forgery that is the >>exploitation that could have resulted in bad reputation. > > > What do you mean the domain owner's reputation can still be exploited? There are some listings that use current domain name accreditation, even though there is nothing to stop the domain from being forged. > What type of reputation system would base abuse assessments upon totally > unconfirmed identifiers? None, I sure hope. But they do exist, even if it is admins fighting the spam battle with local machine rules instead of subscribing to public lists. And you have missed the point, SPF can make the lists better, it cannot make them worse. So worse case is it doesn't make their accuracy better then they already are. > Hopefully, the only confirmed identifiers, > such as the MTA IP address, would then be used. You seem to have missed the point of IP based reputation lists are not sufficient, case and point: the IP repuation lists currently reduce spam, but not even to a bearable amount. > It would be incredible > to have a domain assessed for not publishing an SPF record. I would > even commend them! Ask that their MTA properly confirm their HELO, that > they use S/MIME, DomainKeys, or any other strong method that identifies > the source of the message. SPF's weak and broken authorization scheme > will wreck havoc on email's delivery integrity. You are entitled to your (unsubstantiated) opinion. > > > >>>This is a very real concern being completely ignored by providers >>>anxious to rid themselves of their responsibilities with respect to this >>>menacing abuse. >> >>SPF is not ignoring concerns. The concerns you have stated are either >>unfounded or apply to PRA, not SPF. > > > Both SPF and Sender-ID ignore the identity of the server administrator. Nope, SPFv1 looks at the HELO, Sender-ID does not. Don't confuse SPF with SenderID/PRA. (I need a macro here so I can easily repeat that to you) > Both SPF and Sender-ID premise all assessment upon the domain-owner, > where the server administrator _never_ enters into consideration. Wrong again, the server admin has to do at least *something* to have SPF running on the server. And sometimes, as you argued above, its even the server administrator that takes things into their own hands and publishes on the domain owners behalf, knowing where the MX's are for the domain and its ISP/ESP/hoster. > > > >>>Nevertheless, abating abuse requires holding administrators >>>accountable and ensuring they stay on top of security, access, >>>and operational issues. >> >>Are you suggesting every MTA operator review all inbound email for >>forgery/spam/viruses and do something with the ones that are bad? Glad >>I am not paying that bill. > > > I am suggesting the MTA administrator is the _only_ one that can respond > when there is a security problem, or inappropriate access is being > granted. And if the resources were there for MTA administrators, we wouldn't have a spam problem. But they don't, and so there exists a spam problem. > The MTA administrator should monitor all outbound logs and > watch for excessive errors, or unusual levels of outbound email. Perfect: Oops, a while ago a flood of spam went through our server, sorry I did not notice it before a few million got through. > They > also need to investigate abuse reports of their outbound email. Obviously stated by someone who doesn't spend much time handling user email complaints. > None of > these duties can be expected of the domain owner. For the small time vanity domain where the owner has no idea, doesn't matter, recall your statement above about the ISP/MSP/hoster publishing the SPF on behalf of the domain. Problem solved, even if the domain owner cannot follow the instructions of the various tools to generate SPF records. > The domain owner has > scant few tools to even know when there is a problem, and even fewer for > correcting the situation. The MTA administrator has many tools and can > respond. And does, with SPF, something that is tried, works except on forwarding cases that should never exist anyway, and has measureable deployment. > > > >>>A reputation scheme MUST identify the source of abuse, and not the >>>"assumed" source of abuse. >> >>SPF is not a reputation scheme. >> >>SPF is a means to make reputation schemes accurate by preventing forgery. > > > SPF will not prevent forgery in most cases. Wrong (the current SPF deployment testing shows it), please resist making unsubstantiated claims. > In those cases where > forgery still occurs, disaster! In *what* cases can forgery still occur if SPF is properly implemented? > SPF will change forgery from a nuisance > (remedied with bounce address tag validation), into a total meltdown of > the domain. You really need to avoid making specious claims about what > SPF may accomplish, without also considering what it may not accomplish. You need to avoid making specious claims of problems that are not actually caused by SPF but by PRA. > > > >>>A reputation scheme must hold those responsible, accountable. SPF >>>fails badly on both of these issues. >> >>No, it doesn't. A reputation scheme allows domains to obtain >>credibility (or not) based on what the domain has done in the past. > > > Do you really consider SPF is a means to authenticate the sender? No, neither should you claim that SPF makes the claim. SPF says that the MTA is authorized to send emails from said domain, so the email *could* be legit. SPF does not guarantee emails are good. It just guarantees they are not forged. > What > assumptions are involved when arriving at that conclusion? This is why > SPF is so dangerous. No assumptions, using the same methodolgy that is applied to IP reputation lists, can be provided for domain name reputation lists. Only spammers have lots of IP's for their spamming activity, but fewer domains with good reputation (and the reputation would turn bad after a bit of abuse) > > > >>SPF simply improves the ability for reputation schemes to be accurate by >>preventing forgeries from affecting the reputation database. > > > Publishing SPF does not prevent forgeries. Yes it does. If you cannot trust that the MTA that you allow to send your email cannot be trusted to not send forgeries from your domain, then you have bigger problems with your ISP that not even signature methodolgies can resolve. > Many other protections must > be instantiated, where any missing element in this phalanx of required > protections permits forgery. SPF may even invite forgery. Oh I cannot wait to hear why, please enlighten me with your wisdom. > (Even > assuming it was practical to impose strict authorization to maintain > this claim.) In the typical case, the domain owner will likely be > blithely unaware of the essential elements needed to guard their > reputation. You have already declared that you will permit PRA forgery, > as in your view, this is not your concern. Never said that. In fact I said I would fight the PRA, its worse then useless. > > SPF only offers server authorization. It would be foolish to call this > a forgery prevention scheme, as likely anyone with access to the same *likely* (If you cannot trust your MSP, you need to get a better one). > server may be able to forge messages from a domain that authorizes the > server with SPF. These SPF records are public, so the abuser will not > be guessing who they can impersonate. : ( Your silly, without SPF you can still *easily* find out where the vast of majority of domain names call home, by examining MX and other types of SPf records. > > > >>>It is folly to think SPF will improve the integrity of email or >>>diminish the rate of abuse. A reputation scheme based upon SPF >>>authorization is certain to dramatically reduce email's integrity >>>for the majority of domain owners. >> >>I would love to see your facts, or testing, to justify this statement. >>Sounds like FUD. > > > Yes, I heard that speech several times. I would strongly advise you to > consider strong identifiers that can be defended. A domain owner would > be incredibly foolish to place their domain's reputation into the hands > of an email provider that scoffs at monitoring their server as being too > expensive. While SPF may permit providers a "What, me worry?" attitude, > it will be the consumer that will pay dearly. I will certainly consider other methods of authentication, in fact I would love to. I look forward to one being available, and deployable, and free (as in beer). > > > >>>By retaining a signature operation within their administrative control, >>>the domain owner would have far greater control over the fate of their >>>domain's reputation. >> >>Smells like you want to sell domain owners (or their ISP/MSP) something. >>A certificate perhaps? At least now I know your motivation for >>attacking SPF. > > > Boy are you barking up the wrong tree. Turn around, I think someone > wants to see your license. : ) > Could be, and they can see my license, because I publish SPF. :) > > >>>They could utilize the services of an email provider to relay email >>>from a dynamic location, without fear other abusive messages may be >>>confused as being from them. >> >>Thank you for endorsing the use of SPF (because that is what SPF does, >>only without the need for MUA upgrades to check signatures, and no need >>for buying certificates). > > > You do not need to buy certificates for either DomainKeys or Identified > Internet Mail. I have no financial incentive for recommending either of > these proposals being consider ahead of SPF, other than a desire to see > email remain a viable means to openly exchange information. SPF does > not offer a fig leaf of protection. > > You assume the email provider, who ensures access to the server, also > limits what is sent through the server. In the age of Zombied computers > everywhere, expect anyone with access will try anything. Your only > protection with SPF depends upon a poorly defined set of assurances that > must be made by a dubiously diligent provider. They may believe as you > do, that SPF is its own protection. After all, it would not be their > reputation damaged would it? SPF is not the FUSSP. Never said it was. It just helps to build a better framework so other mechanisms can work better. The fact that in the short term it will quash spammers and viruses who have not adapted is cool, but irrelevant. > > > >>>If their relay provider was lax at security or preventing abuse, the >>>domain owner can seek a different provider to rectify any resulting >>>problems. >> >>Which is a good idea no matter what security protocols one implements >>(or not) for their domain. Hence, thanks for the advice (albeit off >>topic or not specific to SPF). > > > Somehow considering the alternative does seem on topic. > > > >>>You should put yourself into your customer's position. Proclamations >>>that with SPF, some domain can not be forged are specious. >> >>Only when receiving MTA's don't implement SPF (or some other form of >>domain anti-forgery technique). But those MTA's don't matter because >>they won't bother to implement submission of forged emails to domain >>based reputation lists (or would be irresponsible if they did). > > > You have made the point as to why there are advantages avoiding the > publishing of SPF. > I don't see how. > > >>>This of course assumes closed-ended list, where the domain owner >>>maintains exclusive access to their servers. >> >>Please explain, because I don't understand how you could possibly think >>that (recall the include and redirect mechanisms). >> >>It does require that if they relay through their ISP's mail server(s) >>that their ISP publishes SPF, but how is that unreasonable? (No domain >>authentication/authorization scheme can work 100% unless it has 100% >>deployment, and cannot be held responsible for not working where it is >>not deployed) > > > It remains impossible to list servers of those recipients that forward > their email, for example. Please peruse the archives for SRS and SES. > While I have seen it argued this problem is > now the fault of the recipient, it still results in the loss of > messages. If bad "anonymous" forwarding is still allowed. I don't think it should. My servers don't do it, we re-inject so the end rejections come back to the intermediate account. > The remedy is to offer a lowered level of server > authorization, at the expense of being forged at this level. > That's a good point. But not even keys saves you if you cannot trust the MTA that is authorized to send your email. *sigh* > > >>>Closed-ended lists are not practical, nor do most domain owners >>>manage their own MTAs with exclusive access. >> >>Ah, so now you are talking about cross customer forgery within the same >>ISP. Well, either your ISP has to implement protocols to stop cross >>customer forgery (or be proactive about dealing with it, but I don't buy >>that) or we have, let's see, WE HAVE THE MESS WE ARE IN TODAY. > > > But that mess will not impact your domain's reputation, unless you are > silly enough to offer SPF server authorization construed to be "sender > authentication." > Wrong again, I have already encountered small time mail admin who blacklisted my domain name based on an infected computer that had few addresses in the contact list, but one of my sales offices was. Just a local blacklist, not any big damage, but sufficient headache nonetheless. > > >>But bottom line, the majority of forgery I doubt very much comes from >>the same ISP as the domain owner. (That's my experience from my log >>files, its someone else, often over seas, faking to be a user from my >>domain to see if I foolishly white-listed by own domain name). > > > It is futile to go after today's behavior without considering how that > behavior may change. Is it any wonder those promoting SPF don't want to > talk directly about these concerns, and instead treat their audience > like a bunch of patsies ready to believe anything? "Don't listen to > anyone raising concerns about SPF/Sender-ID, they're just trying to > spread FUD!" I have heard this speech several times already. I wonder > if I should take this as a personal attack. ; ) > You can do what you like, its intended as a personal attack. But please stop talking down SPF because PRA has serious flaws, because that is an unfair attack against SPF. > > >>>A domain owner that protects the private portion of their signature, >>>does not depend upon an email provider to protect their reputation. >> >>Unless of course, there are other people in the world how have not >>implemented signature protection. Hmm, where have I heard before there >>could be failures if a protocol doesn't have 100% deployment? > > > The signature can be ignored by the recipient without harm. It only > requires the sender to implement a signature scheme. They then do not > need any protective cooperation by every down stream server, as does > SPF/Sender-ID. > > > >>>Especially an email provider with dubious motives asking them to publish >>>SPF records. How on Earth can publishing an SPF record be in the >>>interest of the domain owner, after Microsoft proclaims server >>>authorization is the same as sender authentication? >> >>If you see the folly of what Microsoft is trying to do to use SPF >>records in ways not intended, GREAT! But that is not fault of SPF. >> >>No matter what they did, the police could not stop my neighbor from >>drinking and driving. Even when they impounded his car he then stole a >>neighbors car. Does this mean that to solve the problem the police >>should take cars away from everyone? No. They put the guy in jail >>because HE was the one that did wrong. >> >>And SPF should not be discouraged because MS is abusing it. MS should >>be stopped from abusing it. > > > How can you say Microsoft is wrong, and an SPF cabal is right? Again, > both drafts even share the same author. Irrelevant, the different drafts are *different* because just that: They say completely different things. > Why blame anyone for there not > being any definition on the scope of the SPF record. Depreciate v=spf1, > advise its removal, and get on with life. > > > >>>A DomainKeys signature associated with the Sender header allows the >>>provider to accept accountability for their customers, without mandating >>>their customers change their email addresses or publish DNS records. >> >>That's a great idea. Let me know when there is a free version of >>DomainKeys. And it works with mailing lists. And it doesn't "violate >>the anonymity" of email (not that I believe that email should be >>anonymous, but that's one of the big whines I hear against correcting >>forwarding). > > > Yes, there is a free version: > http://domainkeys.sourceforge.net/ > You have peaked my interest, I will look at it, domain keys had sounded so much like a money grab before. > > >>>The provider could also offer to relay messages already signed by their >>>customers as well. Either of these scenarios would be fair. >> >>But not free. > > > Yes, free! > As above, I am going to look at it. > > >>>You misunderstood the concern. An email provider likely handles >>>customers using many different mailbox-domains. Yes, there could be >>>cross-user forgery within a domain, but that was not the concern. There >>>could also be cross-domain forgery. The provider is expected to make >>>assurances that some range of domains is permitted specifically for >>>those provided access to the MTA. If the provider does not properly >>>authenticate the user (some still exchange passwords in the clear), or >>>does not evaluate the PRA, the domain owner is placed at risk by >>>publishing SPF records. >> >>Uh, NO. SPF records should not be used to evaluate the PRA. > > > Tell that to Microsoft. Let me know how that goes. : ) MS has made many bad mistakes. They still live with many of them. People still cope by disabling bad ideas like IIS web printing and crap like that. > > >>>The sender does not know what the recipient uses to base their >>>reputation assessments. Someone can get seriously hurt heedlessly >>>publishing SPF. >> >>They do for receivers that correctly implement protocols (e.g. do not >>use SPF records for PRA). >> >>Someone could get seriously hurt if other protocols like TCP keepalives >>are not properly implemented. That doesn't mean we shouldn't use TCP. >>(repeat my drunk driving lecture here). > > > What makes any SPF cabal the protocol authority? The SPF record did not > have a defined scope, where a scope was added when it became apparent > Sender-ID would attempt to use the same silly path registration scheme. > Microsoft claims their algorithm breaks less often and see their claim > equally valid, their view of scope should prevail. > Unsubstantiated claims are irrelevant, which is why Marid ended to allow for testing mode. > > >>>Anyone that utilizes a large provider and publishes an SPF record that, >>>in effect, proclaims such use, could enable an abuser to send from the >>>correct server, while still lying about who they are. SPF does not >>>prevent this problem. >> >>Neither does domain keys, until of course the ISP/MSP upgrades the MTA >>to prevent cross customer forgery. Once that is done, then EITHER >>method works. Amazing, if everything is done then everything works, and >>if only some things are done then only some things work. Fascinating. > > > Sender-ID and SPF depend upon universal checks at each public MTA. > Signatures schemes only requires a sender implementation. But is useless without a receiver implementation. Sound familiar? > > > >>>SPF requires assumed checks that may or may not be performed. In >>>fact, some of these checks may require a license. : ( >> >>Huh? > > > Yes, the PRA you wish would go away. Its back... > But not to stay, not with a license anyway, because many (like myself) will not sign. > > >>>The abuser may wish to play this game until they have scorched the >>>reputation of that domain, before usurping the identity of the next >>>available victim, all while thanking SPF for making their fun possible. >> >>Ditto for any forgery method that can be circumvented. Including >>domainkeys. > > > While forging a message with SPF only requires access to any authorized > server (not even to the SMTP application), and the forgeries can > commence. That can not be said of DomainKeys. > If you cannot trust your MTA, you cannot trust it, not for anything. > > >>>Perhaps the server administration permitted access to the wrong person, >>>perhaps they accidentally enabled an open-proxy in their network, >>>perhaps they even allowed an open-relay. Whatever the problem, the >>>sender often knows where to go for restitution. As SPF is intended to >>>assist the filtering of messages >> >>NO NO NO. It is to be used for MTA time rejection, not post acceptance >>filtering. And SA uses it for post acceptance filtering, but SPF unto >>itself will not cause the email to be rejected due to the incredibly low >>score a FAIL is assigned. > > > You mean no one will ever receive a bad reputation based upon SPF server > authorization? The concern was what happens when they do. > If the reputation lists find that SPF PASS is not sufficient to say its from the domain, that does not preclude SPF still being useful to reject the emails that definitely are *not* from the domain (and even better is the fact that it is done at SMTP time). > > >>>, filtering often employs a practice of >>>placing uncertain results into a junk folder. With SPF, there are many >>>shades of gray. : ( >> >>SPF is *not* PRA. Please stop the FUD. > > > This problem is valid in both cases, and yes worse with PRA. Please > stop attempting to disavow Sender-IDs use of the v=spf1 record. I > suggest if anyone needs to be consulted, you should query the author of > both drafts. > > > >>>The assumption that a mailbox-domain can be authenticated without the >>>use of a signature is fundamentally flawed. >> >>In your opinion, especially if your opinion is to sell domainkeys. The >>only thing that could be considered "flawed" is that it disallows >>anonymous forwarding without implementing some other forwarding method >>(such as SRS, SES). >> >> >>>Server authorization is far >>>too weak to base a presumption of having authenticated the sender. >> >>Your argument does not hold even a drop of substance against the >>HELO/EHLO name checking of SPF. > > > You don't really expect anyone to care about the HELO do you? I hope that someday the poorly configured MTA's will be forced to use a valid HELO. > As far as > SPF is concerned, it is there when the message is a DSN. CSV offers > much lower overhead for this check anyway. Compared to the SPF worst case, yes. Compared to the average case, my understanding is not. > I suspect it will come into > consideration once signatures are prevalent, and then the need will be > more readily perceived. > When signatures actually go into production hopefully all this will be irrelevant. But I doubt it. And we have SPF here, and now. > > >>And it doesn't hold any credence if one (like I) don't believe in >>anonymous forwarding. > > > Thought so, but then you don't care about who is administering the > server. > I don't follow your reasoning. > > >>>Server authorization in the manner of SPF also wrecks havoc on email's >>>architecture. There is no reason for this, when signatures require less >>>effort and create less collateral damage. >> >>But signatures cost more money, requires MTA's everywhere to upgrade >>(even those that don't WANT to participate), how is that not collateral >>damage? > > > These are myths at this point. The overhead required affects the CPU on > the mail server that has adequate margins to permit signatures without > upgrading equipment. Signatures offer less overhead. They even > represent less impact that SPF/Sender-ID. > NO, DNS load can be outsourced to a DNS server, and mitigated by a DNS cache. > > >>>So are you going to tell a 900 pound gorilla they are wrong? In the >>>end, the gorilla will have their way with you. ; ) >> >>The Open source community is a 1000 pound gorilla, once it aligns its >>forces. Just because some big powerful idiot is king, does not mean the >>kings way is right. Look through the history books, its what mutiny and >>revolution are all about. > > > In some areas perhaps. I am 100% behind the open source effort. But be > serious, Microsoft controls too many desktops at this time to be > ignored. You do so, only at your peril. > If you think spam is solved at the desktop. It is not. I don't see how it ever can (or should) because you are still wasting resources allowing the spam to get to the desktop when one could quash it at the MTA. Have you noticed how many peolple have stopped using IE and have started using firefox? Revolution... > > >>>Strange, I see the same author on both drafts? Who's fault is that? >>>Depreciate the use v=spf1 to be assured of avoiding this serious >>>conflict. >> >>Cute. Why can't you just deploy DomainKeys, and let the best product >>win. Why must you resolve to attack SPF? Are you that fearful that SPF >>will succeed in the end that you feel a need to attack it to try to get >>DomainKeys deployment to catch up? > > > I am pointing out what I see is still VERY wrong the SPF draft. I am > placing my comments here because I think SPF, when used in the manner > advocated, place the email community at risk. I would rather provide a > REAL means for people to publish a record that says I DO NOT ASSURE THE > PRA IDENTITY, without that becoming a liability. The way it is > currently defined, SPF is little more than a trap. Not when you can negate the PRA concern with: spf2.0/pra ?all > > -Doug > > -- Terry Fielder terry@greatgulfhomes.com Associate Director Software Development and Deployment Great Gulf Homes / Ashton Woods Homes Fax: (416) 441-9085 From owner-ietf-mxcomp@mail.imc.org Sat May 28 00:58:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02288 for ; Sat, 28 May 2005 00:58:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4S4PkH0002902; Fri, 27 May 2005 21:25:47 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4S4PkDR002901; Fri, 27 May 2005 21:25:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4S4PkMJ002893 for ; Fri, 27 May 2005 21:25:46 -0700 (PDT) (envelope-from pbaker@verisign.com) Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com [65.205.251.34]) by robin.verisign.com (8.13.1/8.12.11) with ESMTP id j4S4PgTg016099; Fri, 27 May 2005 21:25:42 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 27 May 2005 21:25:40 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: SPF PASS (was: "If you believe that the SPF concept is fundam entally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/") Date: Fri, 27 May 2005 21:25:39 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37250302@MOU1WNEXMB04.vcorp.ad.vrsn.com> Thread-Topic: SPF PASS (was: "If you believe that the SPF concept is fundam entally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/") Thread-Index: AcViWGZ5vEsYy7qRTlKtj/g1GErgGwA4+L6w From: "Hallam-Baker, Phillip" To: "Carl Hutzler" , Cc: X-OriginalArrivalTime: 28 May 2005 04:25:40.0438 (UTC) FILETIME=[4E198F60:01C5633D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j4S4PkMJ002894 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Carl Hutzler > Never even knew there was helo checking in SPF. I might have > to do some reading. My bad! It was in at the very start, then it got taken out, then it got put back in again. I think that there had been some discussion about putting HELO checking back in before your comment at the FTC but after that event it became a no-brainer. First there was a major ISP that found that the check had value, second there was absolutely no point in having a standards war over how people make use of SPF records when there is precisely nothing the sender can or should be able to do to dictate how the information is interpreted. I think that all this discussion and techno-politics have caused folk to loose sight of the fact that all we are doing here is providing the receiver with information that might help a recipient decide that he really wants to accept a piece of email. From owner-ietf-mxcomp@mail.imc.org Sat May 28 02:36:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28288 for ; Sat, 28 May 2005 02:36:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4S6BN1g051968; Fri, 27 May 2005 23:11:23 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4S6BNlg051967; Fri, 27 May 2005 23:11:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from winserver.com (ftp.catinthebox.net [208.247.131.9]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4S6BMgh051948 for ; Fri, 27 May 2005 23:11:22 -0700 (PDT) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.1.451.4) for ietf-mxcomp@imc.org; Sat, 28 May 2005 02:12:16 -0400 Received: from ([68.215.118.148]) EHLO=hdev1 by winserver.com (Wildcat! SMTP v6.1.451.4) with SMTP id 1012767578; Sat, 28 May 2005 02:12:14 -0400 Message-ID: <002001c5634b$cb57c0b0$6401a8c0@hdev1> From: "Hector Santos" To: "Hallam-Baker, Phillip" , "Carl Hutzler" , Cc: References: <198A730C2044DE4A96749D13E167AD37250302@MOU1WNEXMB04.vcorp.ad.vrsn.com> Subject: Re: SPF PASS (was: "If you believe that the SPF concept is fundam entally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/") Date: Sat, 28 May 2005 02:09:17 -0400 Organization: Santronics Software, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Hallam-Baker, Phillip" To: "Carl Hutzler" ; Sent: Saturday, May 28, 2005 12:25 AM Subject: RE: SPF PASS (was: "If you believe that the SPF concept is fundam entally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/") > > > [mailto:owner-ietf-mxcomp@mail.imc.org] On Behalf Of Carl Hutzler > > > Never even knew there was helo checking in SPF. I might have > > to do some reading. My bad! > > It was in at the very start, then it got taken out, then it got put back > in again. And I guess, in regards to SPF, I was probably had most of the blame for the debate surrounding this. The issue started with DMP which SPF is based on. DMP has a return path domain check and a HELO client domain (CD) logic: Check Return Path Domain if not pass then check Client Domain When we implemented DMP, it protected our local domains spoofing when the client tried to emulate a internal network client. DMP was extremely simple to explore and implement. Then SPF came along, it was more complex. Not sure of what direction it will take, we held off on it. Once AOL.COM announced support, we began to implement it. SPF had a HELO check but only when the Return Path was NULL if Return Path is NULL check Client Domain else check Return Path Once SPF was implemented, DMP was deprecated. Almost immediately, we began to see spam from clients spoofing our HELO client domain once protected by DMP coming in. It was fairly obvious that the above logic of only checking the HELO domain when the return path was null was not only illogical, it allowed for a spammer loophole into the spec. So I argued for a SPF helo check as well regardless if the return path was null or not. However, by this point, the other implementation issues of DNS based proposals was becoming more obvious - DNS overhead of open-ended lookups. So I understood that there was a concern for redundant checks and given the fact that traditionally the client domain can not relied upon for being correct, my suggestion was to make it optional for implementators but more importantly, I wanted to highlight that the best protection the LMAP protocol had to offer was the protection of local domains (your own). The LMAP results of local domains are more trusted. You can't trust the results of remote domains. Meng and others were not sure which way to go. I thought it was simple issue to realize and important be considerd. It simply can't be ignored. But at the very least, all systems should perform a local domain check and in the final analysis, as we have it today, local domain/IP matching can be done internally and more efficiently. We call it DIP rules (DOMAIN/IP) that is part of our White/Black list filtering before any DNS-based protocol is triggered. In addition, for our implementation, we provided an optional list file to define domains that should be check for SPF client domain names. So we leave it to the administrator as to how much checking he wants to do. The point is basically HELO is important to consider and possibly with the introduction of CSV emphasizing client domain checking, maybe Meng and et decided that it is important to have as well, if only for "competitive" reasons. My argument has always been that if we use a Return Path Domain checking concepts, then this presumes a compliant client. Therefore, it is a new system, and therefore it should never have a invalid HELO client domain name. My assertion has been that it would be illogical to have a SPF return path domain and an non-SPF client domain name. Not possible without something being wrong with the setup, a malicious transaction or a hetergenous topology of mixed systems. result1 := LMAP(ReturnPath, IP) result2 := LMAP(ClientDomain, IP) These mixed policies MUST be consistent (pass or fail) in order for it to work. Its part of the "chain of trust" methodology. I tried to illustrate this point in: http://www.winserver.com/public/antispam/lmap/draft-lmapanalysis1.htm A quick example would be: HELO: localdomain MAIL FROM: remotedomain Which basically says, that if the MAIL FROM domain is remote (meaning, not yours), then having a local domain for HELO is a LMAP violation. In addition, I went further to show that "automated decisions", overhead is further reduced by taken into account a vital piece of the transaction parameters - the forwarding path (RCPT TO). if RCPT is remote then Standard Authentication Required else Rcpt is Local and Not Authenticated Session then check LMAP Anyway, this is what DMP protected. SPF lost focus with HELO with its NULL only rule. The above example is very typical spoofing transaction, about 12% of our total transactions where clients are trying to "fake" the server into thinking it is a internal network machine. In short, if HELO says xxxx.winserver.com xxxx.santronics.com then the IP better be within our IP network, regardless of what the MAIL FROM says. So HELO checking is important and is part of the total scheme of things. But it can't be used by itself like CSV advocates. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com > > I think that there had been some discussion about putting HELO checking > back in before your comment at the FTC but after that event it became a > no-brainer. First there was a major ISP that found that the check had > value, second there was absolutely no point in having a standards war > over how people make use of SPF records when there is precisely nothing > the sender can or should be able to do to dictate how the information is > interpreted. > > I think that all this discussion and techno-politics have caused folk to > loose sight of the fact that all we are doing here is providing the > receiver with information that might help a recipient decide that he > really wants to accept a piece of email. > > From owner-ietf-mxcomp@mail.imc.org Sun May 29 06:11:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06709 for ; Sun, 29 May 2005 06:11:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4T9tZNL041568; Sun, 29 May 2005 02:55:35 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4T9tZhO041567; Sun, 29 May 2005 02:55:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4T9tYxY041548 for ; Sun, 29 May 2005 02:55:34 -0700 (PDT) (envelope-from gim-ietf-mxcomp@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DcKTI-0005zX-Oo for ietf-mxcomp@imc.org; Sun, 29 May 2005 11:52:40 +0200 Received: from 212.82.251.2 ([212.82.251.2]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 May 2005 11:52:40 +0200 Received: from nobody by 212.82.251.2 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 29 May 2005 11:52:40 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-mxcomp@imc.org From: Frank Ellermann Subject: Re: SPF PASS Date: Sun, 29 May 2005 11:52:43 +0200 Organization: Lines: 12 Message-ID: <429990EB.22C3@xyzzy.claranet.de> References: <198A730C2044DE4A96749D13E167AD37250302@MOU1WNEXMB04.vcorp.ad.vrsn.com> <002001c5634b$cb57c0b0$6401a8c0@hdev1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 212.82.251.2 X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hector Santos wrote: [HELO test] > And I guess, in regards to SPF, I was probably had most of > the blame for the debate surrounding this. [...] In one SPF Council meeting Meng wrote "Hector hectored us" (or similar), it sounded more like praise than blame. IIRC it was the s/MAY/SHOULD/ meeting. Bye, Frank From owner-ietf-mxcomp@mail.imc.org Sun May 29 10:52:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20517 for ; Sun, 29 May 2005 10:52:11 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4TEVBf6060743; Sun, 29 May 2005 07:31:11 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4TEVBJu060742; Sun, 29 May 2005 07:31:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4TEVAgv060724 for ; Sun, 29 May 2005 07:31:10 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j4TEV6SP028764; Sun, 29 May 2005 07:31:07 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j4TEV6wZ028761; Sun, 29 May 2005 07:31:06 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sun, 29 May 2005 07:31:06 -0700 (PDT) From: "william(at)elan.net" To: ietf-mxcomp@imc.org cc: spf-discuss@v2.listbox.com Subject: Resent- header fields Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: You probably all know that I have a problem with how SID drafts says Resent header fields are to be used... Well, just out of curiosity I wanted to know how they are they really used in the real world and lucky me I use one of those mail clients that actually supports it (though I've never tried this feature before and kind of came upon it by accident). Anyway, I'm going to demonstrate (and also test it with mail list) in a moment as I forward copy of this post back here with resent headers. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Sun May 29 11:01:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20995 for ; Sun, 29 May 2005 11:01:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4TEi5tD067242; Sun, 29 May 2005 07:44:05 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4TEi5Sf067241; Sun, 29 May 2005 07:44:05 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from mail.completewhois.com (cwhois1.completewhois.com [216.151.192.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4TEi4uB067233 for ; Sun, 29 May 2005 07:44:04 -0700 (PDT) (envelope-from william@completewhois.com) Received: by mail.completewhois.com (Postfix, from userid 500) id 4029F18B13; Sun, 29 May 2005 08:11:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.completewhois.com (Postfix) with ESMTP id 3683A4C06B; Sun, 29 May 2005 08:11:44 -0700 (PDT) X-Return-Path: X-Received: from above.proper.com (above.proper.com [208.184.76.39]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j4TEff7G028850 for ; Sun, 29 May 2005 07:41:43 -0700 X-Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4TEVBf6060743; Sun, 29 May 2005 07:31:11 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) X-Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4TEVBJu060742; Sun, 29 May 2005 07:31:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f X-Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4TEVAgv060724 for ; Sun, 29 May 2005 07:31:10 -0700 (PDT) (envelope-from william@elan.net) X-Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j4TEV6SP028764; Sun, 29 May 2005 07:31:07 -0700 X-Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j4TEV6wZ028761; Sun, 29 May 2005 07:31:06 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sun, 29 May 2005 07:31:06 -0700 (PDT) From: "william(at)elan.net" To: ietf-mxcomp@imc.org Cc: spf-discuss@v2.listbox.com Subject: Resent- header fields Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed List-Archive: List-Unsubscribe: List-ID: X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on sokol.elan.net X-Spam-Status: No, score=0.1 required=6.0 tests=FORGED_RCVD_HELO autolearn=failed version=3.0.0 Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: You probably all know that I have a problem with how SID drafts says Resent header fields are to be used... Well, just out of curiosity I wanted to know how they are they really used in the real world and lucky me I use one of those mail clients that actually supports it (though I've never tried this feature before and kind of came upon it by accident). Anyway, I'm going to demonstrate (and also test it with mail list) in a moment as I forward copy of this post back here with resent headers. -- William Leibzon Elan Networks william@elan.net From owner-ietf-mxcomp@mail.imc.org Sun May 29 12:13:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24113 for ; Sun, 29 May 2005 12:13:02 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4TFtVJK092188; Sun, 29 May 2005 08:55:31 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4TFtV4a092187; Sun, 29 May 2005 08:55:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4TFtTxo092180 for ; Sun, 29 May 2005 08:55:30 -0700 (PDT) (envelope-from william@elan.net) Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j4TFtO0w029499; Sun, 29 May 2005 08:55:24 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j4TFtKS4029496; Sun, 29 May 2005 08:55:20 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sun, 29 May 2005 08:55:20 -0700 (PDT) From: "william(at)elan.net" To: ietf-mxcomp@imc.org cc: spf-discuss@v2.listbox.com Subject: Re: Resent- header fields In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, 29 May 2005, william(at)elan.net wrote: > You probably all know that I have a problem with how SID drafts say > Resent header fields are to be used... > > Well, just out of curiosity I wanted to know how they are they really > used in the real world and lucky me I use one of those mail clients > that actually supports it (though I've never tried this feature before > and kind of came upon it by accident). > > Anyway, I'm going to demonstrate (and also test it with mail list) in > a moment as I forward copy of this post back here with resent headers. Ok, the demonstration with mail lists did not worked quite as I would have liked - mxcomp list-processor stripped off the Resent- header fields and spf-discuss did not let the mail through at all (probably is doing checking on return-path and saw it was not the one I signed up with, even though From and everything else is correct). Anyway, here is what mail header looks like when I resent the message: ------------------------------------------------------------------------- Return-Path: Delivered-To: william@completewhois.com Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by mail.completewhois.com (Postfix) with ESMTP id AAAE918B13 for ; Sun, 29 May 2005 08:07:22 -0700 (PDT) Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j4TEdcI6028819 for ; Sun, 29 May 2005 07:39:38 -0700 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j4TEdcuj028816 for ; Sun, 29 May 2005 07:39:38 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs X-Return-Path: X-Received: from rune.listbox.com (rune.listbox.com [208.210.124.79]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j4TEVVvB028770 for ; Sun, 29 May 2005 07:31:31 -0700 X-Received: from localhost.localdomain (localhost [127.0.0.1]) by rune.listbox.com (Postfix) with ESMTP id 3C3AB18ACF for ; Sun, 29 May 2005 10:31:30 -0400 (EDT) X-Received: from localhost.localdomain (localhost [127.0.0.1]) by rune.listbox.com (Postfix) with ESMTP id 3C3AB18ACF for ; Sun, 29 May 2005 10:31:30 -0400 (EDT) X-Received: from sokol.elan.net (sokol.elan.net [216.151.192.200]) by rune.listbox.com (Postfix) with ESMTP id 94AC6189D6 for ; Sun, 29 May 2005 10:31:11 -0400 (EDT) X-Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id j4TEV6SP028764; Sun, 29 May 2005 07:31:07 -0700 X-Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id j4TEV6wZ028761; Sun, 29 May 2005 07:31:06 -0700 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Sun, 29 May 2005 07:31:06 -0700 (PDT) From: "william(at)elan.net" To: spf-discuss@v2.listbox.com Cc: spf-discuss@v2.listbox.com Subject: [spf-discuss] Resent- header fields Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-spf-discuss@v2.listbox.com Precedence: list Reply-To: spf-discuss@v2.listbox.com List-ID: List-Software: listbox.com v2.0 List-Help: List-Subscribe: , List-Unsubscribe: , Errors-To: listbox+trampoline+735+986489+f3b742cf@v2.listbox.com ReSent-Date: Sun, 29 May 2005 07:39:31 -0700 (PDT) Resent-From: "william(at)elan.net" Resent-To: william@completewhois.com ReSent-Subject: [spf-discuss] Resent- header fields ReSent-Message-ID: -------------------------------------------------------------------------- To be fair, I don't quite agree with how Pine did it as it put Resent- below the reset of the message header and not above it. I looked at RFC2822 and it says there: "All of the resent fields corresponding to a particular resending of the message SHOULD be together. Each new set of resent fields is prepended to the message; that is, the most recent set of resent fields appear earlier in the message." I have a feeling its the word "prepended" that caused problem as some may understand as something being added before (below) the rest of the header data, but its use in RFC2822 seems consistent with how Received fields are added on top of the rest of the header data and example with Resent- is also such that they are added on top. Besides that Pine also quite interestingly changed the data and replaced all trace fields with "X-" (but did not touch any other fields then Received or Return-Path). In any case this all very clearly demonstrates that its new message and not the original when the message is resent. So the use of this for standard non-MUA forwarding is not correct at all and would be in conflict with current systems that currently do use the fields (even if not quite right according to RFC2822, which BTW I intend to report as bug to Pine developers). Yes I know this all does not matter to Microsoft - none of their MUAs like outlook support Resent - but it does not mean others dont and protecting those other systems that follow standards should be more important. --- William Leibzon, Elan Networks: mailto: william@elan.net Anti-Spam and Email Security Research Worksite: http://www.elan.net/~william/emailsecurity/ From owner-ietf-mxcomp@mail.imc.org Sun May 29 17:36:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26481 for ; Sun, 29 May 2005 17:36:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4TKwDWv058063; Sun, 29 May 2005 13:58:13 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4TKwDeG058062; Sun, 29 May 2005 13:58:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4TKwAj9057925 for ; Sun, 29 May 2005 13:58:10 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from [192.168.1.112] (mtsatmE091.snowcrest.net [209.232.214.91]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j4TKvtB6013702 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 29 May 2005 13:57:55 -0700 Subject: Re: draft-schlitt-spf-classic-01.txt From: Douglas Otis To: Terry Fielder Cc: MARID , julian@mehnle.net In-Reply-To: <4297D265.3030307@ashtonwoodshomes.com> References: <1117137745.7537.157.camel@SJC-Office-DHCP-156.mail-abuse.org> <200505262318.03899.bulk@mehnle.net> <1117166528.30777.16.camel@SJC-Office-DHCP-156.mail-abuse.org> <42971610.7090603@ashtonwoodshomes.com> <1117229806.10255.266.camel@SJC-Office-DHCP-156.mail-abuse.org> <4297D265.3030307@ashtonwoodshomes.com> Content-Type: text/plain Date: Sun, 29 May 2005 13:57:54 -0700 Message-Id: <1117400274.9146.152.camel@littlejoy> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 2005-05-27 at 22:07 -0400, Terry Fielder wrote: > Douglas Otis wrote: > > On Fri, 2005-05-27 at 08:44 -0400, Terry Fielder wrote: > > > Publishing SPF, even offering low levels of "server authorization," is > > mistakenly viewed by some as "sender authentication" of the domain. > > Agreed, educate the masses. But good luck, because there are a lot of > computer users without the faintest clue of how things work. Hence why > phishing is so effective. It does not need to be a pad-lock icon to create an impression the sender has been assured. Calling "server authorization" "sender authentication" does little to educate users. If anything, this misrepresentation increases the number of victims, and allows phishers a new means to gain the confidence of their victim. A "happy face" is equally misleading, when this is understood to be that the sender has been authenticated. The mailbox-domain can not be authenticated without a signature. > > Publishing any SPF record unfortunately exposes your domain to > > these widely promoted, but contemptibly false assumptions. > > Yes, along with the false assumption that domainkeys is the FUSSP. Sender-ID/SPF is being touted as a means to accrue reputations based upon the SPF record. This is not an innocuous tool. These weak server authorizations are easily exploited by an abuser. Abuse prevention depends upon the provider's access control and added impositions of mailbox-domain restrictions. By the domain owner publishing the SPF authorization, they enable accrual of a likely unfair reputation. Instead of alerting domain owners as to what is needed for the protection of their domain's reputation, promoters are advising domain owners to consider any concerns over publishing of SPF records to be irrelevant FUD. This is usually accompanied with rhetoric that describes some corner case, and its dismissal. In addition to message loss, I have yet to hear that publishing may cause your domain's reputation to be irreparably damaged, should the provider fail to enforce the new needed restrictions. This failure could happen with the provider enables an open-proxy or open-relay. It may also occur when the provider permits access to their server's other applications that could be subverted into sending mail. No email abuse will be abated without being used in conjunction with a reputation system. There are not the same exposures created by DomainKeys, as with SPF. DomainKeys provides for authentication, whereas Sender-ID does not. > Um, they waged the defense by publishing SPF knowing that means MTA's > that check SPF will reject the forgery of their domain. That *is* > waging the defense. Under particular, impractical circumstances, SPF may allow some emails to be refused on the basis that the server is not authorized. SPF will not prevent the domain being forged, when access is granted to a shared server. When the authorization is open-ended, SPF will not prevent forgery. Again, anti-forgery claims are specious. > Go promote DomainKeys by showing what it has to offer, rather then > trying to raise false and unsubstantiated claims against the competition. Rather than side-stepping this issue, be specific about the claims. > > They may even claim proprietary checks are outside > > their bailiwick, although it then offers an avenue for the forger to > > impugn your reputation. > > SPF is not proprietary. SPF is not PRA. PRA is proprietary. SPF records _will_ be used for the PRA algorithm, that may result in domain's reputation being damaged when ignored and not assured by the provider. > > There are some providers that wish to force use of SPF, and there lies > > the rub. ... > > If the domain providers pushing SPF were so bad, and were doing their > customers so bad, they wouldn't have any customers left: This is a free > society and the masses will take their money and business where they > want to. With a high percentage using a common desktop OS, the influence this creates requires greater consideration. I do not believe the a community will be able to prevent interpretation of a record's scope from being applied to the PRA, without making the scope for the record explicitly expressed. After all, their draft shares the same author, and there was a very short period of time when this was considered permissible within MARID group. > > Millions of users soon will be running an application that will accrue > > "user feedback" against the Purported Responsible Address algorithm > > confirmed with the v=spf1 record, as widely promoted. You would be > > rather foolish to ignore this. > > I do not ignore it. I am very prepared to advise everyone to disable > the PRA when the latest version of exchange/whatever comes out. (Course > I also advise everyone to get rid of M$ Exchange) Again, don't expect to prevail. > > As an expert, you would be negligent advising anyone to publish an > > v=spf1 record, and not insist they also require PRA conflict > > protections. The first question a wary domain owner would need to > > ask, "Do you enforce the PRA for all of your customers?" > > Don't need to, PRA should not be scooping SPFv1 records, they are proven > incompatible. PRA should use their own SPF2.0 records. Don't blame SPF > because PRA is doing something bad, blame PRA. And domain owners have a > defense against the PRA, publish the counter PRA record: > "spf2.0/pra ?all" > so PRA does not misinterpret the SPF as a PRA data. At the same time, domain owners are warned that ?all will eventually become a basis for refusal. This "neutral" authorization, although weak, may still be viewed as confirmation sufficient for expressing some level of "authentication." There have also been warnings regarding the potential damage weak authorizations may create. Forcing the publishing of a PRA record is a strange method to indicate that you refuse to allow the PRA to be evaluated. I would say this suggests just the opposite. > > Offering advice to ignore Sender-ID would be outright laughable, if > > it were not so serious. How will you indemnify your customers from > > such negligence? > > > I advise everyone of the need to ensure PRA is disabled, and if there > are concerns that others they communicate with do not disable PRA then > they should publish the SPF2.0 record: > spf2.0/pra ?all Your customers have NO control over what some recipient may do. This record does not assure their reputation remains protected. In fact, there have been statements made to the opposite. There have also been warnings that in the future this record will be refused. > > Yes, the PRA may make this much worse. What happens at the back-end, > > when the PRA algorithm is a plug-in for Outlook? > > Umm, MTA checking algorithm's should *never* be applied at the MUA, > because its too late to do an MTA reject. > > Don't blame SPF because PRA is bad. > > You keep successfully arguing against PRA, thanks for being on the SPF > side. Too bad you cannot find any legitmate arguments against SPF. Both SPF and Sender-ID proponents proposed the use of reputations based upon server authorization. This raises a legitimate concern. Both SPF and Sender-ID fail to hold the server administrator accountable for the operation of the server, and instead unfairly place the feckless domain owner's reputation at risk. Both SPF and Sender-ID depend upon added restrictions imposed by the email provider, but should the providers fail to perform these new added duties, in addition to their normal duties, the domain owner's reputation is unfairly put at risk. Both SPF and Sender-ID wreck havoc with email's architectural paradigms that will cause the loss of valid emails, and lower the integrity of email delivery. The proponents of Sender-ID claim less loss of messages. The unfair reputation system created by either SPF or Sender-ID will lower the integrity of email delivery as well. > > Now you have both wonderfully weak algorithms being applied to your > > domain, all thanks to SPF. > > No, the wonderfully weak algorithm is because PRA is abusing SPFv1 > records. Move on. You can not prevail on an assumed record scope. Both Sender-ID and SPF attempt to transform "server authorization" into "sender authentication." If I were to authorize an email provider, would that mean any message using my email domain from that provider be from me? > > You need to strongly advise against the use of v=spf1. It must > > go! Don't publish v=spf1 records, and if you have published them, they > > need to be removed, or at least replaced with a different version that > > includes scope. When used for white-listing, the scope "ADMIN" could be > > used. : ) > > No, publish SPF. > > And if someone actually is stupid enough to deploy/enable PRA, then > publish the anti-pra record: > spf2.0/pra ?all One would need to be rather gullible to consider this record is providing any protection, especially for the long term. I would describe this as a trap. With the very few warning made, don't you find these to foretell intended strategies? > >> Domain owners can be exploited if they don't publish SPF, nothing > >> changes by publishing SPF except, if SPF really does work (as time has > >> shown once forwarders are fixed), SPF may prevent forgery that is the > >> exploitation that could have resulted in bad reputation. > > > > What do you mean the domain owner's reputation can still be exploited? > > There are some listings that use current domain name accreditation, even > though there is nothing to stop the domain from being forged. Accreditations often depend upon the IP address in the same manner as an SPF record. This type of service is often used by bulk emails. These providers likely enjoy exclusive access to the "authorized" servers. However, exclusive access should not be a requirement for a typical domain owner. It is often not the case. Even so, not publishing SPF still affords this domain owner greater protection. > > What type of reputation system would base abuse assessments upon totally > > unconfirmed identifiers? > > None, I sure hope. But they do exist, even if it is admins fighting the > spam battle with local machine rules instead of subscribing to public > lists. And you have missed the point, SPF can make the lists better, it > cannot make them worse. So worse case is it doesn't make their accuracy > better then they already are. I do not agree. SPF hopes to make this practice endemic. Filtering is attempting to treat a disease, while also lowering email's integrity. Only with strong and definitive results, can email's integrity be retained. Signatures are strong and do not alter email's architectural paradigms. SPF is weak, and breaks email. > > Hopefully, the only confirmed identifiers, > > such as the MTA IP address, would then be used. > > You seem to have missed the point of IP based reputation lists are not > sufficient, case and point: the IP repuation lists currently reduce > spam, but not even to a bearable amount. The degree to which IP address lists are ineffective is dependent upon the diligence afford by large providers to administer their services. SPF will only likely cause these providers to be less diligent and assume there can be reliance upon SPF server authorization. This will result in there being a total mess, and a disaster for many otherwise responsible domain owners who will loss their ability to utilize their domains. > > Both SPF and Sender-ID premise all assessment upon the domain-owner, > > where the server administrator _never_ enters into consideration. > > Wrong again, the server admin has to do at least *something* to have SPF > running on the server. And sometimes, as you argued above, its even the > server administrator that takes things into their own hands and > publishes on the domain owners behalf, knowing where the MX's are for > the domain and its ISP/ESP/hoster. The domain owner must publish the SPF record. The domain owner is not the email provider running the authorized servers. > > I am suggesting the MTA administrator is the _only_ one that can respond > > when there is a security problem, or inappropriate access is being > > granted. > > And if the resources were there for MTA administrators, we wouldn't have > a spam problem. But they don't, and so there exists a spam problem. Funny, SPF expects these same providers to do even more, but I suspect they will do even less. > > The MTA administrator should monitor all outbound logs and > > watch for excessive errors, or unusual levels of outbound email. > > Perfect: Oops, a while ago a flood of spam went through our server, > sorry I did not notice it before a few million got through. Your reputation should suffer, and not your customer's. > > They also need to investigate abuse reports of their outbound email. > > Obviously stated by someone who doesn't spend much time handling user > email complaints. I did say should. : ) Even so, the lax provider will not harm their reputation under the SPF reputation strategy, it will be their customers. How self serving. > > None of these duties can be expected of the domain owner. > > For the small time vanity domain where the owner has no idea, doesn't > matter, recall your statement above about the ISP/MSP/hoster publishing > the SPF on behalf of the domain. Problem solved, even if the domain > owner cannot follow the instructions of the various tools to generate > SPF records. I can see you don't care the least what happens when reputation is applied. > > The domain owner has > > scant few tools to even know when there is a problem, and even fewer for > > correcting the situation. The MTA administrator has many tools and can > > respond. > > And does, with SPF, something that is tried, works except on forwarding > cases that should never exist anyway, and has measureable deployment. Blame decades of use of a valuable feature? > > SPF will not prevent forgery in most cases. > > Wrong (the current SPF deployment testing shows it), please resist > making unsubstantiated claims. > > > In those cases where > > forgery still occurs, disaster! > > In *what* cases can forgery still occur if SPF is properly implemented? Exactly! > > SPF will change forgery from a nuisance > > (remedied with bounce address tag validation), into a total meltdown of > > the domain. You really need to avoid making specious claims about what > > SPF may accomplish, without also considering what it may not accomplish. > > You need to avoid making specious claims of problems that are not > actually caused by SPF but by PRA. It will plague both. > > Do you really consider SPF is a means to authenticate the sender? > > No, neither should you claim that SPF makes the claim. SPF says that > the MTA is authorized to send emails from said domain, so the email > *could* be legit. > SPF does not guarantee emails are good. It just guarantees they are not > forged. Wrong again. > > What > > assumptions are involved when arriving at that conclusion? This is why > > SPF is so dangerous. > > No assumptions, using the same methodolgy that is applied to IP > reputation lists, can be provided for domain name reputation lists. > Only spammers have lots of IP's for their spamming activity, but fewer > domains with good reputation (and the reputation would turn bad after a > bit of abuse) The use of a name offers greater freedom for imposing reputation. There are potentially more names than addresses. > > Publishing SPF does not prevent forgeries. > > Yes it does. If you cannot trust that the MTA that you allow to send > your email cannot be trusted to not send forgeries from your domain, > then you have bigger problems with your ISP that not even signature > methodolgies can resolve. How can a domain owner know how well their ISP defends their domain's reputation. What recourse do they have when they don't? > > Many other protections must > > be instantiated, where any missing element in this phalanx of required > > protections permits forgery. SPF may even invite forgery. > > Oh I cannot wait to hear why, please enlighten me with your wisdom. Access. > > (Even > > assuming it was practical to impose strict authorization to maintain > > this claim.) In the typical case, the domain owner will likely be > > blithely unaware of the essential elements needed to guard their > > reputation. You have already declared that you will permit PRA forgery, > > as in your view, this is not your concern. > > Never said that. In fact I said I would fight the PRA, its worse then > useless. By ignoring the PRA, you and your customer becomes its victim. > > SPF only offers server authorization. It would be foolish to call this > > a forgery prevention scheme, as likely anyone with access to the same > > *likely* (If you cannot trust your MSP, you need to get a better one). That will not remove the damage. > > server may be able to forge messages from a domain that authorizes the > > server with SPF. These SPF records are public, so the abuser will not > > be guessing who they can impersonate. : ( > > Your silly, without SPF you can still *easily* find out where the vast > of majority of domain names call home, by examining MX and other types > of SPf records. Usurping SPF based reputations requires SPF records. > >> I would love to see your facts, or testing, to justify this statement. > >> Sounds like FUD. > > > > > > Yes, I heard that speech several times. I would strongly advise you to > > consider strong identifiers that can be defended. A domain owner would > > be incredibly foolish to place their domain's reputation into the hands > > of an email provider that scoffs at monitoring their server as being too > > expensive. While SPF may permit providers a "What, me worry?" attitude, > > it will be the consumer that will pay dearly. > > I will certainly consider other methods of authentication, in fact I > would love to. I look forward to one being available, and deployable, > and free (as in beer). What problem do you see with DomainKeys for example? > > You do not need to buy certificates for either DomainKeys or Identified > > Internet Mail. I have no financial incentive for recommending either of > > these proposals being consider ahead of SPF, other than a desire to see > > email remain a viable means to openly exchange information. SPF does > > not offer a fig leaf of protection. > > > > You assume the email provider, who ensures access to the server, also > > limits what is sent through the server. In the age of Zombied computers > > everywhere, expect anyone with access will try anything. Your only > > protection with SPF depends upon a poorly defined set of assurances that > > must be made by a dubiously diligent provider. They may believe as you > > do, that SPF is its own protection. After all, it would not be their > > reputation damaged would it? > > SPF is not the FUSSP. Never said it was. It just helps to build a > better framework so other mechanisms can work better. The fact that in > the short term it will quash spammers and viruses who have not adapted > is cool, but irrelevant. SPF does NOT build a better framework. Just the opposite. It leads to very bad results when authorization is consider to be the same as authentication. > > It remains impossible to list servers of those recipients that forward > > their email, for example. > > Please peruse the archives for SRS and SES. > > > While I have seen it argued this problem is > > now the fault of the recipient, it still results in the loss of > > messages. > > If bad "anonymous" forwarding is still allowed. I don't think it > should. My servers don't do it, we re-inject so the end rejections come > back to the intermediate account. All of this looks like a real mess. > > > The remedy is to offer a lowered level of server > > authorization, at the expense of being forged at this level. > > > > That's a good point. But not even keys saves you if you cannot trust > the MTA that is authorized to send your email. *sigh* The domain owner only needs to trust the signing process and not each and every MTA involved in the delivery of their message. > > How can you say Microsoft is wrong, and an SPF cabal is right? Again, > > both drafts even share the same author. > > Irrelevant, the different drafts are *different* because just that: They > say completely different things. They both use the same record for different mailbox-domains and then presume the sender on that basis. Really bad. > > Sender-ID and SPF depend upon universal checks at each public MTA. > > Signatures schemes only requires a sender implementation. > > But is useless without a receiver implementation. Sound familiar? Signatures only requires that the end-points implement the protocol to be beneficial. SPF or Sender-ID requires each and every MTA implement the protocol, or their reputation can become seriously damaged. > > Yes, the PRA you wish would go away. Its back... > > > > But not to stay, not with a license anyway, because many (like myself) > will not sign. You are setting yourself up for being forced into using the PRA it would seem. > > While forging a message with SPF only requires access to any authorized > > server (not even to the SMTP application), and the forgeries can > > commence. That can not be said of DomainKeys. > > > > If you cannot trust your MTA, you cannot trust it, not for anything. Not true. It can still be trusted with a signature based system. Just like the WiFi at the coffeeshop can only be trusted with end-to-end encryption. > > You mean no one will ever receive a bad reputation based upon SPF server > > authorization? The concern was what happens when they do. > > > If the reputation lists find that SPF PASS is not sufficient to say its > from the domain, that does not preclude SPF still being useful to reject > the emails that definitely are *not* from the domain (and even better is > the fact that it is done at SMTP time). Perhaps this small feature would be useful, but I doubt that will ever be practical when considering the impact this has on forwarded email. The danger happens when too many consider this useful as a basis of sender authentication, and then use it to apply reputations. > When signatures actually go into production hopefully all this will be > irrelevant. But I doubt it. And we have SPF here, and now. Neither signatures, or Sender-ID will protect network resources. The requirement of over one hundred lookups by SPF also can not be defended. CSV however does offer a means to thwart attacks. > > These are myths at this point. The overhead required affects the CPU on > > the mail server that has adequate margins to permit signatures without > > upgrading equipment. Signatures offer less overhead. They even > > represent less impact that SPF/Sender-ID. > > > > NO, DNS load can be outsourced to a DNS server, and mitigated by a DNS > cache. There is still the effort needed to obtain the many SPF records for each and every message. > > I am pointing out what I see is still VERY wrong the SPF draft. I am > > placing my comments here because I think SPF, when used in the manner > > advocated, place the email community at risk. I would rather provide a > > REAL means for people to publish a record that says I DO NOT ASSURE THE > > PRA IDENTITY, without that becoming a liability. The way it is > > currently defined, SPF is little more than a trap. > > Not when you can negate the PRA concern with: spf2.0/pra ?all This is wishful thinking. -Doug From owner-ietf-mxcomp@mail.imc.org Tue May 31 06:10:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23815 for ; Tue, 31 May 2005 06:10:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4V9n95v009382; Tue, 31 May 2005 02:49:09 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4V9n9ap009381; Tue, 31 May 2005 02:49:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from procserver.webwayone.co.uk (webway-one-02.hiway.co.uk [62.8.115.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4V9n75M009359 for ; Tue, 31 May 2005 02:49:08 -0700 (PDT) (envelope-from SRS0=c/d3GA25=UG=webwayone.co.uk=graham@webwayone.co.uk) DomainKey-Signature: a=rsa-sha1; s=procserver; d=webwayone.co.uk; c=nofws; q=dns; h=from:to:subject:references:date:in-reply-to:message-id: user-agent:mime-version:content-type; b=PL02OKbI8wM95rHuIZ/xOy/nylgTWmNqR8v1Bo/VuZ2TJNpnUnJMWL8vMkdwBB2IA zXif3C9acb3LZhPDYFgSw== Received-SPF: none (procserver.webwayone.co.uk: domain of graham@webwayone.co.uk does not designate permitted sender hosts) receiver=procserver.webwayone.co.uk; client-ip=192.168.50.45; envelope-from=; helo=gmdev.webwayone.co.uk; Received: from gmdev.webwayone.co.uk (graham@gmdev.webwayone.co.uk [192.168.50.45]) by procserver.webwayone.co.uk (8.13.4/8.13.4) with ESMTP id j4V9nlDi027757 for ; Tue, 31 May 2005 10:49:53 +0100 From: Graham Murray To: ietf-mxcomp@imc.org Subject: Re: draft-schlitt-spf-classic-01.txt References: <1117137745.7537.157.camel@SJC-Office-DHCP-156.mail-abuse.org> <200505262318.03899.bulk@mehnle.net> <1117166528.30777.16.camel@SJC-Office-DHCP-156.mail-abuse.org> <42971610.7090603@ashtonwoodshomes.com> <1117229806.10255.266.camel@SJC-Office-DHCP-156.mail-abuse.org> <4297D265.3030307@ashtonwoodshomes.com> <1117400274.9146.152.camel@littlejoy> Date: Tue, 31 May 2005 09:49:00 +0000 In-Reply-To: <1117400274.9146.152.camel@littlejoy> (Douglas Otis's message of "Sun, 29 May 2005 13:57:54 -0700") Message-ID: <87sm03zpwz.fsf@gmdev.webwayone.co.uk> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (i586-suse-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Douglas Otis writes: > You can not prevail on an assumed record scope. Both Sender-ID and SPF > attempt to transform "server authorization" into "sender > authentication." If I were to authorize an email provider, would that > mean any message using my email domain from that provider be from me? I cannot comment on Sender-ID, but as I understand it (as the one who publishes SPF records for the domain) SPF does not attempt to do this. An SPF pass does *NOT* indicate that the mail is genuinely from the domain (though in the cases of the domains I control it probably does as I also control the mail servers), but an SPF fail indicates that the mail is definitely NOT genuinely from the domain. So an SPF pass should not be counted as sender authentication, even domain keys does not do this (it only authenticates the domain and that the mail has not been 'tampered with')- if you want to authenticate the sender you will have to use an MUA cryptographic system like S/MIME or PGP/MIME etc. From owner-ietf-mxcomp@mail.imc.org Tue May 31 11:11:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17412 for ; Tue, 31 May 2005 11:10:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VEn2VO089222; Tue, 31 May 2005 07:49:02 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4VEn2PL089221; Tue, 31 May 2005 07:49:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from arsenet-princip.ArSeNet-LasRozas.local (212.85.32.32.arsenet.com [212.85.32.32] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VEmxdM089213 for ; Tue, 31 May 2005 07:49:00 -0700 (PDT) (envelope-from owner-spf-help@v2.listbox.com) Received: from mail pickup service by arsenet-princip.ArSeNet-LasRozas.local with Microsoft SMTPSVC; Tue, 31 May 2005 16:46:32 +0200 thread-index: AcVl74b1K05nHmD7TEK4eiCRdtcIvw== Delivered-To: juan@equinoccio.com X-AV-Scanned: yes 8f2d524c56d70c3f5ae998356bda52c5 Message-ID: <017901c565ef$86f83610$fa01a8c0@ArSeNetLasRozas.local> X-Injected-Via-Gmane: http://gmane.org/ To: , "IMB Recipient 1" From: "Frank Ellermann" Subject: [spf-help] Re: SPF and SenderID Date: Tue, 31 May 2005 16:46:28 +0200 Organization: Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 References: <4295C2D0.1000801@234.cx> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-212.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) Cc: Reply-To: List-Id: List-Software: listbox.com v2.0 List-Help: List-Subscribe: , List-Unsubscribe: , X-OriginalArrivalTime: 31 May 2005 14:46:32.0500 (UTC) FILETIME=[894C5F40:01C565EF] Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Pete Chown wrote in spf-help: > What should I do now? Is there a way of supporting SPF > without helping to get a patented technology established > on the Internet? Sure. MS pretends to control spf2.0/pra to a certain degree, as defined in draft-lyon-senderid-pra-01 They certainly don't control all of spf2.0, as defined in draft-lyon-senderid-core-01 They never controlled a single bit of v=spf1 as defined in draft-schlitt-spf-classic-01 As long as you don't want PRA this doesn't affect you, v=spf1 is an open standard (wannabe from the IETF's POV, there's yet no RfC for it). MS tried to pull the stunt that v=spf1 is by default a part of PRA. This is a lie, the IESG knows that it's a lie, so senderid-lyon-core-01 can never pass as an RfC. Bye, Frank (Cc: mxcomp) ------- Archives at http://archives.listbox.com/spf-help/current/ Donate! http://spf.pobox.com/donations.html To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/?member_id=1449865&user_secret=615bee79 From owner-ietf-mxcomp@mail.imc.org Tue May 31 15:34:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11294 for ; Tue, 31 May 2005 15:34:32 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VJ7KZO008399; Tue, 31 May 2005 12:07:20 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4VJ7K3J008398; Tue, 31 May 2005 12:07:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VJ7Jnp008390 for ; Tue, 31 May 2005 12:07:19 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id C6DC1414F0; Tue, 31 May 2005 12:07:14 -0700 (PDT) Subject: Re: draft-schlitt-spf-classic-01.txt From: Douglas Otis To: Graham Murray Cc: ietf-mxcomp@imc.org In-Reply-To: <87sm03zpwz.fsf@gmdev.webwayone.co.uk> References: <1117137745.7537.157.camel@SJC-Office-DHCP-156.mail-abuse.org> <200505262318.03899.bulk@mehnle.net> <1117166528.30777.16.camel@SJC-Office-DHCP-156.mail-abuse.org> <42971610.7090603@ashtonwoodshomes.com> <1117229806.10255.266.camel@SJC-Office-DHCP-156.mail-abuse.org> <4297D265.3030307@ashtonwoodshomes.com> <1117400274.9146.152.camel@littlejoy> <87sm03zpwz.fsf@gmdev.webwayone.co.uk> Content-Type: text/plain Date: Tue, 31 May 2005 12:07:14 -0700 Message-Id: <1117566434.7521.132.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 2005-05-31 at 09:49 +0000, Graham Murray wrote: > Douglas Otis writes: > > > You can not prevail on an assumed record scope. Both Sender-ID and SPF > > attempt to transform "server authorization" into "sender > > authentication." If I were to authorize an email provider, would that > > mean any message using my email domain from that provider be from me? > > I cannot comment on Sender-ID, but as I understand it (as the one who > publishes SPF records for the domain) SPF does not attempt to do this. An SPF > pass does *NOT* indicate that the mail is genuinely from the domain (though in > the cases of the domains I control it probably does as I also control the mail > servers), but an SPF fail indicates that the mail is definitely NOT genuinely > from the domain. So an SPF pass should not be counted as sender > authentication, even domain keys does not do this (it only authenticates the > domain and that the mail has not been 'tampered with')- if you want to > authenticate the sender you will have to use an MUA cryptographic system like > S/MIME or PGP/MIME etc. Not granting an RFC for Sender-ID will not prevent the promised use of the PRA algorithm with version 1 SPF records. While you may not desire such PRA treatment of your email, publishing _any_ SPF record, as currently defined, enables use of the PRA algorithm. The way this use can be prevented would be to depreciate version 1 SPF records, and to define scopes with version 2 SPF records that clearly indicate which identities are 'assured' within messages. Also add a scope of 'ADMIN' where no identifiers are assured, to allow the SPF records be used for purely white-listing purposes. Being practical, remove the HELO scope from the SPF records. CSV can assure a single lookup for this purpose, and CSV offers a mechanism to declare domain-wide email policies, to increase email requirements of such things as CSV itself, or email signing, etc. In this way, CSV offers DoS protections for any subsequent email extension. Many have commented that a "benefit" of SPF is it forces abusers to use their 'real' domain name, so they can be identified and stopped. This comment illustrates an expectation that SPF provides "sender authentication" where an abuser can not forge the mailbox-domain. While possible, with add restrictions imposed by the email provider, the domain owner remains completely at the mercy of an email provider's diligence at _every_ MTA involved in the transport of the message, and not just those MTAs that have been directly authorized by the SPF record. A mistake on the part of an email provider, such as misconfiguration of a firewall, and the domain owner's reputation suffers. A domain owner will have few resources to know the cause of their reputation woes, and will need to wait for the TTL of their SPF records to expire, before ill-advised publishing can be retracted, assuming they even know which servers are at fault. SPF offers many shades of gray, such as Pass, Neutral, SoftFail, or TempError. An abuser could have their forged messages accepted at any of these levels. Reputation and "assumed sender authentication" will combine to sort out these results. It is very likely an abuser, finding they _can_ forge a domain with a published SPF record, will cause the messages from that domain to become filtered and redirected into junk folders. As the reputation factor becomes more significant, there may then be an outright rejection of the message from the forged domain. Once the message becomes rejected, meaning the reputation is now badly tainted, the recovery of the domain for email may be extremely difficult. Such a system is sure to cause the integrity of email delivery to suffer. Controlling abuse requires the administrator of the email server to play a critical role. Essentially, it requires that they control access to the server. Use of an IP address or the DomainKey signature will directly impact the administrator of the significant (offending) email server. SPF may not affect such administrator. Hence a possible lackadaisical attitude regarding their obligations. To abate abuse, there must be a low tolerance for abuse, and strong identifications for the source of the abuse. Once there is any blocking put in place, it should directly impact the administrator of the email server causing the problem. SPF may eventually provide feedback to the domain owner, but the domain owner may have no ability to meaningfully respond in a timely manner. At that point, they may also have no ability to recover either. It is not surprising so little is being said about the implied duties required to protect domain owners when they publish SPF records, or the potential for the harm that may result. As far as the email provider is concerned, the less said the better. A naive domain owner is willing to risk their reputation without asking for any indemnification from their provider. At this time, there is no SPF record that can be published without also requiring the PRA be examined and assured. The many different mailbox-domains must be limited to those domains allowed for each authenticated user. With SPF, providers must vet who is allowed to use a particular domain, and be sure to enforce each and every identity that _could_ be used in any SPF related reputation scheme. The "opt-out" scenario described by Sender-ID is really little more than a ploy to have domain owners publish PRA specific records. This record strategy is already prone to the Machiavellian "user feedback" button. Ignoring Sender-ID would be at your peril. At some point, snap. -Doug From owner-ietf-mxcomp@mail.imc.org Tue May 31 16:57:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00124 for ; Tue, 31 May 2005 16:57:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VKZlGN014143; Tue, 31 May 2005 13:35:47 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4VKZl9P014142; Tue, 31 May 2005 13:35:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4VKZlnE014115 for ; Tue, 31 May 2005 13:35:47 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from SJC-Office-DHCP-156.Mail-Abuse.ORG (SJC-Office-DHCP-156.Mail-Abuse.ORG [168.61.10.156]) by harry.mail-abuse.org (Postfix) with ESMTP id 21AE3414F0; Tue, 31 May 2005 13:35:42 -0700 (PDT) Subject: Re: Resent- header fields From: Douglas Otis To: "william(at)elan.net" Cc: ietf-mxcomp@imc.org In-Reply-To: References: Content-Type: text/plain Date: Tue, 31 May 2005 13:35:41 -0700 Message-Id: <1117571741.7521.159.camel@SJC-Office-DHCP-156.mail-abuse.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 2005-05-29 at 08:55 -0700, william(at)elan.net wrote: > > On Sun, 29 May 2005, william(at)elan.net wrote: > > To be fair, I don't quite agree with how Pine did it as it put Resent- > below the reset of the message header and not above it. I looked at > RFC2822 and it says there: > > "All of the resent fields corresponding to a particular resending of the > message SHOULD be together. Each new set of resent fields is prepended > to the message; that is, the most recent set of resent fields appear > earlier in the message." > > I have a feeling its the word "prepended" that caused problem as some > may understand as something being added before (below) the rest of the > header data, but its use in RFC2822 seems consistent with how Received > fields are added on top of the rest of the header data and example with > Resent- is also such that they are added on top. > > Besides that Pine also quite interestingly changed the data and replaced > all trace fields with "X-" (but did not touch any other fields then > Received or Return-Path). In any case this all very clearly demonstrates > that its new message and not the original when the message is resent. > > So the use of this for standard non-MUA forwarding is not correct at > all and would be in conflict with current systems that currently do > use the fields (even if not quite right according to RFC2822, which BTW > I intend to report as bug to Pine developers). Yes I know this all does > not matter to Microsoft - none of their MUAs like outlook support Resent - > but it does not mean others dont and protecting those other systems that > follow standards should be more important. The use of the RFC822 standard does not mandate the ordering of headers. RFC822 is to be supplanted by a proposed standard, which is about to become less relevant itself, with yet another proposed standard. Due to a long legacy of use, email compliance should expect an ability to handle standard formats, in addition to accommodating changes being made in proposed standard formats. -Doug From owner-ietf-mxcomp@mail.imc.org Wed Jun 1 02:28:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03309 for ; Wed, 1 Jun 2005 02:28:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5164ZVR074047; Tue, 31 May 2005 23:04:35 -0700 (PDT) (envelope-from owner-ietf-mxcomp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j5164ZCM074045; Tue, 31 May 2005 23:04:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-mxcomp@mail.imc.org using -f Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5164ZUA074036 for ; Tue, 31 May 2005 23:04:35 -0700 (PDT) (envelope-from dotis@mail-abuse.org) Received: from [192.168.2.11] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by b.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j5164YTR015768 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 31 May 2005 23:04:34 -0700 Subject: Re: draft-schlitt-spf-classic-01.txt From: Douglas Otis To: Hector Santos Cc: ietf-mxcomp@imc.org In-Reply-To: <003a01c56663$77c853e0$6401a8c0@hdev1> References: <1117137745.7537.157.camel@SJC-Office-DHCP-156.mail-abuse.org> <200505262318.03899.bulk@mehnle.net> <1117166528.30777.16.camel@SJC-Office-DHCP-156.mail-abuse.org> <42971610.7090603@ashtonwoodshomes.com> <1117229806.10255.266.camel@SJC-Office-DHCP-156.mail-abuse.org> <4297D265.3030307@ashtonwoodshomes.com> <1117400274.9146.152.camel@littlejoy> <87sm03zpwz.fsf@gmdev.webwayone.co.uk> <1117566434.7521.132.camel@SJC-Office-DHCP-156.mail-abuse.org> <003a01c56663$77c853e0$6401a8c0@hdev1> Content-Type: text/plain Date: Tue, 31 May 2005 23:05:24 -0700 Message-Id: <1117605924.2710.114.camel@bash.adsl-64-142-13-68> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit Sender: owner-ietf-mxcomp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 2005-06-01 at 00:36 -0400, Hector Santos wrote: > > While possible, with add restrictions imposed by the email provider, > > the domain owner remains completely at the mercy of an email > > provider's diligence at _every_ MTA involved in the transport of the > > message, and not just those MTAs that have been directly authorized > > by the SPF record. A mistake on the part of an email provider, such > > as misconfiguration of a firewall, and the domain owner's reputation > > suffers. > > And how is CSV immune from these same set of possible routing scenarios? The HELO name would be indicative of the domain administrator running the MTA, irrespective of the mailbox-domains contained in messages sent by the MTA. If the MTA is not properly administered, it would be this MTA and the administrator of this MTA identified by a reputation scheme that rates HELO names. Those that would normally send messages over a HELO blocked MTA would be free to look elsewhere to obtain email services. If the mailbox-domains were rated and blocked instead, as with SPF, a poorly maintained MTA could continue to send abusive and even forged emails, but then the domain owners would find use of their domains blocked, no matter which other provider they tried. Not fair for the domain owner, nor effective at preventing abuse. : ( > Are you saying that once CSV authorizes a submission at the MSA, then there > is no need to further perform CSV during the route and only at the MDA? CSV would be checked once for every HELO presented. The basis of any reputation should be with respect to the administrator. Only the administrator is in a position to take immediate and knowledgeable corrective action. Normally an administrator's reputation evaluation would only need to be done once for any number of messages. Unlike SPF, which may entail many many lookups, CSV requires just one for its basic use, and done just once per MTA for a substantial reduction in overhead. This low overhead makes CSV suitable for protecting network resources. > What if you have this topology? > > MUA ---> MSA1/MTA1 -----> MTA2 ----> MDA3 > > MSA1 and MDA3 is CVS ready. MTA2 is not. > > How does MDA3 handle this using CSV? What is the policy here? CSV offers a means to protect network resources on a name basis. CSV would permit name reputation accrual for the MTA, rather than just for its address as done today. Thus updating addresses would not impact the MTA administrator to the same extent as it does today. As CSV uses the SRV record, there would be no address maintenance involved in an address change either. (Beyond the normal A record reassignment of the interface of course.) By elevating the network reputation protection service to the name space, rather than just address space, CSV offers a means to extend DoS protections for other uses, such as email signatures as described in: http://www.ietf.org/internet-drafts/draft-otis-mass-reputation-01.txt CSV also provides a means to establish domain-wide assertions without the use of wildcards as well. Of course this would be greatly facilitated by a convention that expects the HELO to resolve to a CSV record. If MDA2 claimed to be from a domain that had a domain-wide policy that required a CSV record (per the SRV Port assertions), then a lack of such a record would become a basis for MTA3 to refuse messages from MTA2. There could also be a simple fallback that depends upon an address space reputation service, instead of name space. Regardless of the use of addresses or HELOs, there is no expectations that new conventions are adhered to by each MTA. The HELO name would be authenticated directly, and would be acting under the auspices of the MTA administrator. On top of this network HELO name reputation protection scheme, a signature domain name reputation protection scheme could be constructed. In either case, HELO or signature domain, the name reputation would reflect the diligence of the administrator guarding access at each MTA. Of course, in the case of the signature, this provides valuable end-user protections, and not network resource protections. Signature schemes would also assist MTA administrators identify problematic accounts without unfair assumptions. CSV and Signatures are fair and safe alternative to path registration. -Doug