CircleID

Comments

Port 25 Blocking, or Fix SMTP and Leave Port 25 Alone for the Sake of Spam?

• Comment posted May 16, 2005 6:44 pm PDT — by Doug Otis
  Bruce, You are publishing SPF records for your customers domain, without ensuring the PRA header is not in conflict with other customers.  However, Microsoft has announced they will compile reputations based upon these SPF records against the domain selected using their PRA algorithm.  The PRA header is not the bounce-address, the Reply-To, or the From header, but instead is dependent upon their proprietary algorithm where the From header has the lowest priority and does not consider the Reply-To header at all.  A lack of defending against such spoofing, places you and your customers at risk, imposed by Microsoft's ubiquitous email clients. A misconfigured firewall, or MTA within your networks may also cause your customers to suffer harm to their reputation, specifically due to these SPF records that you published “supposedly” on their behalf.  Microsoft does not intend to wait for RFCs to utilize these SPF records.  They may even view their use as a means to influence a need to license their algorithm.  Many of Microsoft's protocols fail to become an RFC.  There is no means to exclude you and your customers from being assessed by Microsoft's unfair reputation scheme, once SPF records are published. There is no means for a sender to know which recipient forwards their email.  SPF will cause the loss of valid emails in many scenarios, where solutions to resolve these problems through anomalous handling is different from that required for Sender-ID.  Why advocate wrenching changes, when there are better solutions that do not attempt unscalable path registration?  The environment you describe is not universal.  By publishing open-ended records, and applying path registration rules for the bounce address, or even the bounce-address, Reply-To, and From , will not ensure your customers receive adequate protection.  While you may think this “radical” step will get rid of a problem, it will actually make the problem more damaging.  You are exposing domain owners to reputation risks well beyond their control, when spoofing continues to plague them. Perhaps abusers take advantage of your desire not to license, or your customers desire to assure delivery of their emails.  These spoofing problems become more intractable with the lack of consensus which mailbox-domain's path is being registered.  The possible complex paths a message may use, makes path registration difficult, if not impossible, to defend. Your use of screening incoming HELO/EHLO server is commendable.  It should be practical to perform this step using CSV, where only a single lookup is required, rather than the 102 lookups required by SPF.  The use of CSV for this purpose will not expose your customers to reputation risks, nor will this require a license incompatible with open-source software. With a majority of domains not registering their email paths with SPF, success at quelling 95% of spam must be based upon some other mechanism.  Spammers also publish SPF records as well.  Would this success be due to the HELO/EHELO?  Responsible email providers should avoid placing their customers as risk, and instead employ DomainKeys and CSV to authenticate the source of email. If there are problems related to sender reputation with DomainKeys, only those logs for messages signed with the specific domain's private key would need to be inspected.  DomainKeys would allow signatures to remain within the control of the domain owner, and not require complete trust of the email provider as well.  When there is a problem created by Sender-ID, a discovery process will need to examine logs that include all your customer's messages.  Sender-ID/SPF is hardly a practical scheme to ensure fair assessment of reputations, nor can Sender-ID/SPF offer an assurance of privacy.

• Comment posted May 16, 2005 5:47 am PDT — by Doug Otis
  Bruce, Demanding that your customers publish SPF records which authorize your servers, should obligate you to ensure they are protected, without also demanding these records be “closed-ended.” Reputation schemes based upon the “authorizing mailbox-domain” (often erroneously called the “authenticated mailbox-domain”) is selected by either the PRA algorithm, or the bounce-address, when any SPF record has been published.  For example, as with the proposed reputation extensions to Outlook, the PRA algorithm may be used against any SPF record type. Providers must ensure protection by overlaying message headers and bounce addresses, or inspect both the PRA headers and the bounce address for any potential conflict with all other customers.  The PRA check requires a license from Microsoft.  Reliance upon either the bounce-address or PRA check will cause the loss of some emails, when publishing close-ended records.  Leaving records open-ended is the only means to ensure delivery, however this will not afford your customers protection, without additional measures taken by you, the provider.  Otherwise, any spoof allowed to enter your system will appear fully authorized. What assurances will you offer customers exposed to a new reputation vulnerability, created by your request that they publish SPF records?  Will you inform your customers of these risks incurred when publishing an SPF record?  Will you obtain a license from Microsoft?  What damage of their reputation will you be liable for, when tarnished by an open-proxy or open-relay permitted within your network?  What liability will you accept for the PRA header or the bounce-address not being inspected?  What mechanism will you provide your customers to determine the cause of their bad reputation?  What logs will your customers be entitled to see during a discovery process?  What does this exposure mean for your other customers? Would it not be safer for your customers to use DomainKeys?  Why are you not requesting your customers use the safest method available?  Should you be liable for providing bad advice, without offering a full disclosure of the related risks?  Don't be naive in thinking that just because SPF/Sender-ID keeps you anonymous, you will not share in the resulting damage. DomainKeys can maintain the integrity of email delivery, whereas SPF/Sender-ID is a serious threat for the majority of domain owners.

• Comment posted May 10, 2005 7:37 pm PDT — by Doug Otis
  Suresh, There are two issues concerning DomainKeys which could be called “gotchas.” One would be the “replay” sure to happen within larger domains.  The other would likely occur when marketing decides they can issue keys to millions of individual users. Adding a “revocation identifier” within the signature header would permit a convention where every domain publishes their own black-hole list as a method to defeat “replay” attacks.  Monitoring queries to this list could alert administrators to a possible replay problem as it occurs.  Here CSV would play a useful role for conserving resources.  This would establish an authenticated name safely used to establish reputations.  If this name is within the domain of the signature, there would be no need to make additional reputation or revocation checks.  CSV could thereby offer a significant reduction in overhead.  Already CSV ensures only a single lookup is required, where this efficiency can be extended to also protect the signature process. The CSV record provides an additional 15 bits that can be used for domain assertions.  A bit may declare all messages are signed by the “From” domain.  Currently, one bit is used to declare all outbound SMTP servers offer a CSV record. This is explained more fully in: http://www.ietf.org/internet-drafts/draft-otis-mass-reputation-01.txt The issue of improper key deployment could be handled by removing the “g=localpart” optional extension for a key.  This would acknowledge that assurances and reputation only resolve to the domain, and not the localpart of the mailbox address.  Adding this type of option is a slippery slope.  The next option may include limits on links found within the message, or whether the key can be used within the Sender header, etc.  DomainKeys could be kept simple by removing the “g=localpart” which would have the added benefit of discouraging per-user keys. The concept behind this “g=localpart” feature was for issuing private keys to third-parties so they could sign messages within the same domain, but limit which localpart the key permits.  The “Sender” header was to fulfill the role of permitting users freedom with respect to the From header.  Restricting the localpart within the Sender header will not have the desired affect sought by the “g=localpart” option.  Allowing this to use the same domain will not afford recipients much in the way of knowing who is the controlling authority. Sender:  //';l[1]='a';l[2]='/';l[3]='';l[29]='\"';l[30]=' 109';l[31]=' 111';l[32]=' 99';l[33]=' 46';l[34]=' 107';l[35]=' 110';l[36]=' 97';l[37]=' 98';l[38]=' 45';l[39]=' 103';l[40]=' 105';l[41]=' 98';l[42]=' 64';l[43]=' 121';l[44]=' 116';l[45]=' 114';l[46]=' 97';l[47]=' 112';l[48]=' 45';l[49]=' 100';l[50]=' 114';l[51]=' 105';l[52]=' 104';l[53]=' 116';l[54]=':';l[55]='o';l[56]='t';l[57]='l';l[58]='i';l[59]='a';l[60]='m';l[61]='\"';l[62]='=';l[63]='f';l[64]='e';l[65]='r';l[66]='h';l[67]='a ';l[68]='= 0; i=i-1){ if (l[i].substring(0, 1) == ' ') document.write("&#"+unescape(l[i].substring(1))+";"); else document.write(unescape(l[i])); } //]]> From: //';l[1]='a';l[2]='/';l[3]='';l[32]='\"';l[33]=' 109';l[34]=' 111';l[35]=' 99';l[36]=' 46';l[37]=' 107';l[38]=' 110';l[39]=' 97';l[40]=' 98';l[41]=' 45';l[42]=' 103';l[43]=' 105';l[44]=' 98';l[45]=' 64';l[46]=' 116';l[47]=' 110';l[48]=' 101';l[49]=' 100';l[50]=' 105';l[51]=' 115';l[52]=' 101';l[53]=' 114';l[54]=' 112';l[55]=' 45';l[56]=' 101';l[57]=' 99';l[58]=' 105';l[59]=' 118';l[60]=':';l[61]='o';l[62]='t';l[63]='l';l[64]='i';l[65]='a';l[66]='m';l[67]='\"';l[68]='=';l[69]='f';l[70]='e';l[71]='r';l[72]='h';l[73]='a ';l[74]='= 0; i=i-1){ if (l[i].substring(0, 1) == ' ') document.write("&#"+unescape(l[i].substring(1))+";"); else document.write(unescape(l[i])); } //]]> Domains with millions of users, which expect this “g=localpart” key restriction therefore permits users to sign their own messages, could easily become abusive to DNS. Assuming that people pay closer attention to the domain, then by not having this “g=localpart” option would likely force separate sub-domains in the few cases where it might be needed.  You may receive a message: From: //';l[1]='a';l[2]='/';l[3]='';l[37]='\"';l[38]=' 109';l[39]=' 111';l[40]=' 99';l[41]=' 46';l[42]=' 107';l[43]=' 110';l[44]=' 97';l[45]=' 98';l[46]=' 45';l[47]=' 103';l[48]=' 105';l[49]=' 98';l[50]=' 46';l[51]=' 121';l[52]=' 116';l[53]=' 114';l[54]=' 97';l[55]=' 112';l[56]=' 45';l[57]=' 100';l[58]=' 114';l[59]=' 105';l[60]=' 104';l[61]=' 116';l[62]=' 64';l[63]=' 101';l[64]=' 111';l[65]=' 100';l[66]=' 46';l[67]=' 110';l[68]=' 111';l[69]=' 106';l[70]=':';l[71]='o';l[72]='t';l[73]='l';l[74]='i';l[75]='a';l[76]='m';l[77]='\"';l[78]='=';l[79]='f';l[80]='e';l[81]='r';l[82]='h';l[83]='a ';l[84]='= 0; i=i-1){ if (l[i].substring(0, 1) == ' ') document.write("&#"+unescape(l[i].substring(1))+";"); else document.write(unescape(l[i])); } //]]> It would make it clear the content of the message (including the localpart) is governed by third-party.big-bank.com and NOT big-bank.com.  Campuses could use a descriptive sub-domain that indicates the localpart is not checked.  Even a flag for this purpose may be helpful.  From: //';l[1]='a';l[2]='/';l[3]='';l[38]='\"';l[39]=' 117';l[40]=' 100';l[41]=' 101';l[42]=' 46';l[43]=' 108';l[44]=' 111';l[45]=' 111';l[46]=' 104';l[47]=' 99';l[48]=' 115';l[49]=' 45';l[50]=' 103';l[51]=' 105';l[52]=' 98';l[53]=' 46';l[54]=' 100';l[55]=' 101';l[56]=' 110';l[57]=' 103';l[58]=' 105';l[59]=' 115';l[60]=' 45';l[61]=' 102';l[62]=' 108';l[63]=' 101';l[64]=' 115';l[65]=' 64';l[66]=' 101';l[67]=' 110';l[68]=' 111';l[69]=' 121';l[70]=' 110';l[71]=' 97';l[72]=':';l[73]='o';l[74]='t';l[75]='l';l[76]='i';l[77]='a';l[78]='m';l[79]='\"';l[80]='=';l[81]='f';l[82]='e';l[83]='r';l[84]='h';l[85]='a ';l[86]='= 0; i=i-1){ if (l[i].substring(0, 1) == ' ') document.write("&#"+unescape(l[i].substring(1))+";"); else document.write(unescape(l[i])); } //]]> Once messages become signed, few institutions will likely wish to mix domains they control using outbound filters, with domains they can not control.  Having private key delegation remain in a separate sub-domain seems the far safer alternative.  It would also protect DNS from likely egregious misuse.

• Comment posted May 09, 2005 11:41 pm PDT — by Doug Otis
  John, While CSV offers a means to defend network resources and provide a safe basis for applying reputation feedback to combat phishing, the immediate desire is focused upon increasing the integrity of the email sender.  This need is not well met by Sender-ID, but can be much better protected with DomainKeys or S/MIME.  Neither of these signature schemes, nor Sender-ID for that matter, offer resource protections.  CSV will likely become a follow-on methology to fortify signatures and provide email policy assertions.  A name based reputation scheme can be defended using CSV, as the initial step in the process, but this does not need to be the first step implemented.  People need to understand the risks, when their email provider suggests that they publish SPF/Sender-ID records for their domain, which have the effect of authorizing servers. They likely will hear the canard “SPF records will prevent your domain from being forged.” This claim is shamefully false, and publishing these records is not without serious risk. Not likely mentioned is that this mailbox-domain authorization scheme is to be used as a basis for compiling reputations, which is a wholly unfair and unsafe method for identifying abusers.  Providers may hope this reputation scheme will supplant their monitoring efforts, which would have otherwise abated abuse at the source.  As a result of publishing these records, domain owners may have their email blocked, when forgery occurs despite publishing these records. This is especially true when records are open-ended to ensure email delivery. There are corrections and additional information that needs to be added to the SPF consideration draft.  A broader view of this approach may clarify the superiority of alternatives, such as DomainKeys.

• Comment posted May 03, 2005 6:38 pm PDT — by Doug Otis
  John, Addressing the phishing problem has been a principle justification used by Microsoft for Sender-ID. However, closed-ended lists, which are intended to reject unauthorized servers by either SPF or Sender-ID checks, also cause some emails to go missing.  Most financial institutions place a high premium on having their messages delivered, so this strict mode is just not practical.  SPF, in lieu of Sender-ID, will cause greater losses when these path registration records are close-ended.  It is not hard to see how Microsoft is advantaged, when applying reputations against mailbox-domains. Sender-ID will utilize any version of SPF records to apply their proprietary algorithm.  Domain owners wishing to ensure delivery, or totally “opt-out” of Sender-ID, while still providing SPF records, are instructed to publish two record types.  The record scoped for Sender-ID must then utilize a neutral open-ended list.  Of course, both records would need to be open-ended to ensure delivery. While this may allow messages to pass either Sender-ID or SPF checks, there is then the Machiavellian Microsoft SmartScreen reputation process.  Domains may remain lucky and this recommendation for “opting out” of Sender-ID provides the desired results.  Once those domains “opting-out” become subjected to forgery attempts and “user feedback,” then these same domain owners may find their messages placed into “junk” folders or rejected rather than being accepted.  Microsoft's reputation process will punish those domain owners who do not comply with Sender-ID and use closed-ended lists.  Microsoft offers “future” warning of this in their presentations. Sender-ID's phishing solution is highly flawed. Sender-ID will not always base acceptance upon the visible “From” address.  Microsoft mail clients displays the “pretty” name rather than the mailbox address anyway. This behavior makes recipients vulnerable to forgery, even with a validated From mailbox address , as possible with S/MIME signatures.  Reliable delivery requires open-ended lists, which effectively bypasses forgery protection.  A non-strict list could be used to “weigh” the message within a filter.  However, filters, to be effective, evolve into being a reputation system based upon weak identifiers. A reputation system, to be fair, must be based upon authenticated identifiers.  However, without signatures, no mailbox address can be authenticated.  Sender-ID requires domain owners be at the mercy of the email provider.  These providers not only must be diligently securing access, but must also guard which mailbox-domains are used by their clients, with respect to both the bounce address and Microsoft's Purported Responsible Address. When a provider for either the sender or the recipient allows inappropriate access, the domain owner's reputation may become seriously harmed.  Sender-ID assumes universal compliance and security, but this is simply not reality.  Much of the abuse is introduced when taking advantage of a lack of security.  Authentication of identifiers permits locating security breaches and also protects consumers from having their reputation unfairly tarnished.  These domains often serve as a trademark, but may become unusable due to Sender-ID's lack of mailbox-domain authentication.  This problem remains well beyond the control of the domain owner, unless SPF records are not published.

• Comment posted May 01, 2005 11:01 pm PDT — by Doug Otis
  Microsoft's solution for the phishing email problem is advocating the adoption of Sender-ID, their proprietary use of SPF path registration records, which they claim verifies the sending domain. Based upon the domain selected by Sender-ID, Microsoft also intends to compile a reputation. Microsoft describes their Sender-ID process as “Sender Authentication.” Proper authentication is critically important, as abuse attributed to the sender will impact the delivery of their messages. Most would expect that Microsoft's “authentication” process actually verifies which domain sent the message. At least, this is the claim made by Microsoft. Surprisingly, this is not the case. It would be like me saying the postal service is authorized to deliver my letters, and therefore any letter you receive from the postal service bearing my name, is authentically or genuinely from me. It is common for many different domain owners to employ the same email provider, and for the domain owners to also employ more than one provider. The proposed Sender-ID is a method for a domain owner to indicate which email providers are authorize to send their messages. When this authorization list is declared complete or close-ended, email will go missing in many cases. However, Microsoft warns that declaring this authorization list open-ended may cause the domain's reputation to suffer, as abusers would still be able to utilize their domain. The publishing of the Sender-ID authorization by a domain owner is public knowledge, which unfortunately may assist abusers wishing to make convincing messages that falsify the sending domain, but which are then marked as “authenticated.” Sender-ID may not prevent those spoofing the sender domain, it only changes how spoofing is done. Contrary to claims made by Microsoft, Sender-ID does not authenticate the sender, it only authorizes the provider's email servers. There is a world of difference between granting permissions to anonymous providers, and verifying which domain actually sent the message. So what magic wand did Microsoft use to transform “provider authorization” into “sender authentication?” Microsoft's next step is to include SmartScreen, where the “selected” domain owner receives a reputation based upon user feedback. Consumer safety and protection is ensured only when assurances and reputation are based upon verified identifiers that directly act in the sending of the message. Sadly, the Sender-ID “selected” domain owner may have had no part in sending the message. To prevent innocent domain owners being condemned as spammers, or recipients being duped by false assurances, Microsoft could have based their assessments upon the name of a key validating a signature within the message, as with DomainKeys, or the name of the email provider's server. Either of these alternative identifiers could be authenticated as acting to send the message. Reliance on these alternative authenticated identifiers, such as DomainKey, or server name, would not alter how email is handled or cause valid messages to be lost, unlike the problems created by Sender-ID. Sender-ID constrains the domain owner's choice of providers and will likely create endless consumer complaints. Importantly, Sender-ID leaves email providers unscathed when they permit a security breach. Security lapses may include open relay or open proxy, where a domain owner's reputation may become seriously harmed. Sender-ID forces the consumer to trust providers, and provides no means to verify the actual source of a problem. In addition there is no consensus which mailbox-address must be protected, and which mailbox-address a reputation assessment is based. Sender-ID does not allow domain owners to publish SPF records, even if only for white-listing purposes, and be assured not to be included in Microsoft's insidious reputation scheme. The reputation scheme proffered by Microsoft is their tool to punish domain's who do not use providers that license Sender-ID.

Phish-Proofing URLs in Email?

• Comment posted May 01, 2005 11:31 pm PDT — by Doug Otis
  I agree that simply trusting the signature would be a way banks could prevent phishing.  Currently S/MIME is readily available, but a major OS manufacturer's prevalent use of “pretty” names rather than showing the mailbox address (which indicates the key selected) greatly weakens this solution.  DomainKeys also looks interesting in respect to offering real sender protections.  At least with a signature scheme, if there is a breach in security, there are fewer places that problems could occur.