Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Spam America Online

AOL Now Publishing SPF Records 340

Posted by CowboyNeal from the slowly-gaining-ground dept.
SPF Fan writes "It looks like SPF is starting to catch on with the bigger ISPs. AOL is now publishing SPF records which you can verify with 'dig aol.com txt'. Will Hotmail and Yahoo be far behind? Who else is publishing SPF records for their domains? Slashdot has covered SPF in the past a couple times."
This discussion has been archived. No new comments can be posted.

AOL Now Publishing SPF Records More

AOL Now Publishing SPF Records

Comments Filter:
  • How does AOL know my SPF [dermstore.com] and why do they want other people to have access to it? Are they that concered at the prospect of me getting a sunburn?

  • Suggestion for submitter (Score:4, Insightful)

    by ObviousGuy ( 578567 ) <ObviousGuy@hotmail.com> on Friday January 09, 2004 @04:05AM (#7926237) Homepage Journal
    Don't assume we all know what "SPF" is. Unless you mean "Sun Protection Factor", you are leaving the /. readers to wonder.

    Please, if discussing a topic that is not widely known, put a short description or definition in the article writeup.

    Thanks.

  • AOL (Score:4, Funny)

    by joostje ( 126457 ) on Friday January 09, 2004 @04:06AM (#7926241)
    Who else is publishing SPF records for their domains?

    [AOL]
    Me Too!
    [/AOL]

  • I publish SPF records (Score:4, Informative)

    by karl.auerbach ( 157250 ) on Friday January 09, 2004 @04:06AM (#7926242) Homepage
    I've been publishing SPF records for the cavebear.com domain for about two months now.

    I've only done the publishing side, I have not yet enabled my mail servers to use them.

    Even though SPF may not be a complete or perfect solution, I see no harm in announcing to the world that if it purports to come from my domain than it also comes from my designated mail servers.
    • Even though SPF may not be a complete or perfect solution, I see no harm in announcing to the world that if it purports to come from my domain than it also comes from my designated mail servers.

      I think most average users don't really care how it is done, it has become a "just do it" issue.

      For websites that need to be able to accept mail from previously unknown senders, a challenge/response shouldn't be a big impediment to the senders as long as they know why it is being done.

      Maybe I'm way out in lef
    • We don't need this in the USA. We have made forging spam email headers illegal! They are going to fade away just like drugs and assualt weapons.
    • I've been a customer of pobox.com for probably seven years now. It's a mail forwarding service that originally started in a dorm room and grew into a business - mail to bill dot stewart at pobox dot com forwards to me@my-isp.example.com, and I can change it any time I change ISPs. When I send mail to somebody, the IP address isn't pobox.com's servers - it's whatever IP I'm connecting from, whether that's my home DSL, or my DSL provider's smtp relay, or my office's firewall smtp relay, or my mailbox/shell

      • That's what SASL is for (Score:3, Interesting)

        by dszd0g ( 127522 )
        Simple Authentication and Security Layer allows a user to identify themselves to a mail server. POBOX just needs to set up a mail server that uses SASL and then their users use that to send mail.

        This is often referred to as SASL auth or sometimes SMTP auth.

        They probably need to set it up on both port 25 and another port generally 587 in case users ISPs block connections to port 25.

        Alternatively there are older solutions that may work for some mail services like POP before send. Where any IP address tha

  • omg... (Score:2, Informative)

    by neodymium ( 411811 )
    ...thats 9 class c networks only for sending spa^H^H^Hmail

  • Catching on (Score:3, Interesting)

    by Tom ( 822 ) on Friday January 09, 2004 @04:09AM (#7926258) Homepage Journal
    I only learned about SPF recently, but ever since I've been publishing SPF records for my domain.

    It appears to be one of these "why didn't I think of that?" solutions that go and take care of a problem without ripping out everything around it.

  • How about dynamic IPs? (Score:4, Insightful)

    by ivern76 ( 665227 ) on Friday January 09, 2004 @04:34AM (#7926345)

    This just screws the people on dynamic IPs even more than we were before. I guess I'll have to keep paying a monthly fee just so I can have a smarthost to tunnel my mail through, since even more mail servers are going to think I'm a spammer now.

    • If you're on a dynamic IP you'll find a lot of your email gets bounced by Yahoo/AOL (at least) already for being on a dial-up blacklist. You simply can't send mail reliably from a dynamic IP these days, but I won't miss the spam.

      In the UK we have plenty of choice for broadband ISPs who offer fixed IPs at no extra cost (which is why I'm moving away from BT Openworld who charge an extra 10 a month for the privilege)
    • According to the site, DynDNS lets you publish SPF records if you want to. Don't know if you have to pay extra, but DynDNS is pretty reasonable :)
    • First of all, why can you use the machine you receive mail on to send mail? Obviously that IP doesn't change too often.

      And in any event, most dynamic IPs are within a certain net block. so you can simply add that net block to your SPF record. I'm assuming you have your own domain here.

  • Why this is a big deal (Score:5, Informative)

    by mattbee ( 17533 ) <matthew@bytemark.co.uk> on Friday January 09, 2004 @04:45AM (#7926370) Homepage
    It means that any system administrator can configure their mail transfer agent to bin any spam pretending to come from aol.com with a 100% success rate. And this goes for anyone else publishing an SPF record for your domain.

    SPF [pobox.com] is a proposed standard for a domain owner to tell mailers where mail From: that domain may originate. The domain owner publishes a DNS TXT record for their domain with (at the simplest) list of IP addresses. Participating mail transfer agents can then look this record up and make a policy decision on whether the mail is likely to be legitimate. The presence of an SPF record on a domain at present means that while you still can't be sure when you're handling spam, you can be sure when you have a piece of non-spam because the SPF record tells you so.

    SPF is not a wholly original idea (e.g. up "designated mailer protocol"), and certainly not the simplest implementation but the important factor is that its proponent, Meng Wong, is an excellent lobbyer and spokesperson, as well as someone who as the nous to put forward a useful protocol (he founded pobox.com). It's currently at the point where lots of implementation are being written, with the canonical version being Meng's Perl modules. Currently I'm helping to finish the C implementation which will shortly be integrated into qmail [cr.yp.to] and exim [exim.org].

    The tipping point (I hope) will be when a domain not publishing an SPF record or publishing a globaly permissive one will be considered "obviously" untrustworthy. Combining SPF authorisation with a more traditional "From: domain blacklist" will give spammers a very very hard time indeed forging mail. But AOL publishing a record (we hope) shows the way the wind is blowing: the rest of the world does seem to have to change their mail server configuration to keep mail flowing to AOL.

    So go on, it's dead easy, publish a record for your domain now. Tell people where your mail comes from. Look, there's even a wizard to help you [pobox.com].

    • Re:Why this is a big deal (Score:3, Informative)

      by Malc ( 1751 )
      It does break forwarded messages. I have my Yahoo mail automatically forwarded to my own server. For me to use SPF on my mail server, Yahoo would have to re-write the FROM field in the envelope so that it appears to come from their domain. Obviously I'd like them to implement SPF-based filtering at the same time.

    • Re:Why this is a big deal (Score:5, Informative)

      by jeroenvw ( 566364 ) <jeroen@wol f f e l a a r . nl> on Friday January 09, 2004 @07:05AM (#7926815) Homepage
      The presence of an SPF record on a domain at present means that while you still can't be sure when you're handling spam, you can be sure when you have a piece of non-spam because the SPF record tells you so.

      So, as a spammer, you only have to publish an SPF for your own domain, and your mail is garanteed to be nonspam?

      No, you have it wrong: Mail coming from hosts not allowed by the SPF, is guaranteed to violate the policy of the sender domain. SPF is basically saying: ``Hey, to whom is interested, mail coming from one of oud adresses, will always be send by these mailservers. So if you receive them from other means... We didn't do it!''

      But indeed, if the domain and its users are trustworthy, you may decide that spam isn't likely to come from them. While ISP's might be trustworthy themselves, their users as a whole are not.

      the rest of the world does seem to have to change their mail server configuration to keep mail flowing to AOL.

      Wrong again, it's about mail flowing FROM @aol.com adresses. Mail going TOWARDS aol has nothing to do with it. Even if AOL will be implementing SPL while recieving mail themselves, if you don't use SPL, you're not blocked, and also, you need to change your DNS, not your mail server, if you want to implement SPL for outgoing mail of your domain.

    • Re:Why this is a big deal (Score:4, Informative)

      by Zocalo ( 252965 ) on Friday January 09, 2004 @08:21AM (#7927146) Homepage
      Just a quick clarification, but an "SPF record" is not, strictly speaking, a DNS TXT record type. The SPF RFC defines a new DNS record type called as you might expect, "SPF" which is the preferred way of doing things:

      @ IN SPF "<spf string>"

      However, in order to get things off the ground without having to wait for DNS servers and tools to support a new record type, it is also possible to publish the same information in a TXT record:

      @ IN TXT "<spf string>"

      If your DNS server supports the SPF *type*, then you should ideally use that and provide the TXT record as a backup. Query tools that properly support SPF will probably look for the SPF type first and then requery for TXT on a failure, but it's up to the developer of course.

  • anti-spoofing (Score:5, Interesting)

    by colinleroy ( 592025 ) on Friday January 09, 2004 @04:48AM (#7926380) Homepage
    As I don't think this will stop spam (at least not before massive adoption, as others said), I think it can protect us from having a spammer using our email address as From:.
    I publish SPF records for my small domain now, and next time some dumb ISP complains getting spam "from me", I'll be able to tell them to go and check my SPF records, and to match these with "my" spam's headers.

    Of course, this is for my little domain with few users, all well-educated enough to use authenticated SMTPS to my server.
  • I read the page but it's too early in the morning for me. Would someone please explain the idea behind SPF _understandably_?

    • Re:Would someone explain this to a simpleton? (Score:5, Informative)

      by Motherfucking Shit ( 636021 ) on Friday January 09, 2004 @06:06AM (#7926617) Journal
      I read the page but it's too early in the morning for me. Would someone please explain the idea behind SPF _understandably_?
      Suppose you own a domain, let's call it sharpfang.com. You have a cable modem and your IP address is always 24.95.x.x. If you're sending out email from sharpfang.com, you always do it from your cable modem.

      One day, you start getting a lot of bounced spam. Some spammer, for some reason, has decided that he would forge his latest batch of spam from @sharpfang.com email addresses. What a dick!

      So, you set up SPF records for your domain. The SPF records are basically a way of telling other mail servers, "I only send mail from my cable modem connection, which will always have an IP of 24.95.x.x. If you get mail claiming to be from sharpfang.com, but it didn't come from an IP address inside 24.95.0.0/24, it's bogus!"

      Now, enlightened mail server admins can reject any email with an @sharpfang.com return address but an origin IP of somewhere outside of 24.95.0.0/24. Of course, if your IP address or range changes (e.g. you're traveling, you switch ISPs) you simply update your SPF records in DNS.

      SPF has dual benefits: it can reduce the load you get from joe-jobs (assuming some of the recipients' mail servers honor SPF), and it helps everyone else identify spam.

  • Some of the benefits. (Score:4, Interesting)

    by mcroot ( 634911 ) on Friday January 09, 2004 @04:51AM (#7926389)
    Some people seem to be missing the point of spf. SPF is a mechanism that allows people to publish their own records to defend themselves against joe-jobbing. Anyone who has been joe-jobbed will be all over something like this. The fact that publishing these records benefits you directly, will help something like this spread in a timely manner.

    It's also beneficial in the regard that when rolled out to where it becomes standard, mail will be far more accountable, and as spammers start joe-jobbing those people who have not yet published these records, it will only help motivate those hold-outs to get on the bandwagon and defend themselves.

  • This does reduce spam (Score:5, Informative)

    by dybdahl ( 80720 ) <info@@@dybdahl...dk> on Friday January 09, 2004 @04:52AM (#7926393) Homepage Journal
    It reduces spam because spamfilters like spamassassin etc. can add extra points to those e-mails that did not verify against SPF records.

    If Red Hat adds SPF verification to their default spamassassin configuration files, a lot of companies will start to add SPF records to their DNS.

    If I send an e-mail to a RoadRunner mailbox, it is rejected. Why? Because my mailserver is a Linux box on my ADSL internet connection, and RoadRunner blocks all e-mails from residential IP ranges. With SPF, such filtering can be made much more careful, making it possible for me to send e-mails to RoadRunner customers again.
    • If I send an e-mail to a RoadRunner mailbox, it is rejected. Why? Because my mailserver is a Linux box on my ADSL internet connection, and RoadRunner blocks all e-mails from residential IP ranges. With SPF, such filtering can be made much more careful, making it possible for me to send e-mails to RoadRunner customers again.

      Why don't you use your ISP's mail relay? That's what it's for. i switched from relaying my mail via my ISP's smtp server to directly sending it to the recipients's MX for one day, and I

  • Spamassassin will support it in 2.70 (Score:4, Informative)

    by KjetilK ( 186133 ) <kjetilNO@SPAMkjernsmo.net> on Friday January 09, 2004 @05:05AM (#7926432) Homepage Journal
    Hm, I must have been living under a rock, because it is the first time I hear about it. However, it sounds like a good idea, I have to contact my upstream ISP to have them add a record for me.


    Anyway, it seems SpamAssassin will be adding support for SPF in 2.70, at least according to bug 2143 [spamassassin.org]. That's cool!

  • SPF is a really bad idea (Score:2, Interesting)

    by ^BR ( 37824 )

    Are you used to sending personnal email (one that have another domain than your employers in the From: address) from work using your company SMTP server as a relay? You know, the only one you have access to with many reasonable security policies...

    Can't do that anymore, your message will be flagged as spam by the recipient server if he checks for SPF records.

    Have AOL warned its customers of this little side effect of it implementing SPF?

    Plus SPF technically wise sucks, it should have been a new re

    • Re:SPF is a really bad idea (Score:4, Insightful)

      by colinleroy ( 592025 ) on Friday January 09, 2004 @05:19AM (#7926487) Homepage
      SPF implementation guidelines specify that admins specifying their SPF records should also enable SMTPS authentication. With this you'll be able to send your personal mail from everywhere using your domain's SMTP server.
      See step 2 on the "How do I implement SPF" [pobox.com] page.

      • This doesn't help much.... (Score:3, Interesting)

        by ^BR ( 37824 )

        What if I don't have access to the authorized relay, as in all company outgoing mail must go through company SMTP server, wether it as a @company.com from address or a @vanitydomain.com address.

        If you read personnal email at work (bad) but keep it separate from your professionnal email (good) this will greatly inconvenience you.

        And what about the consultant on a customer's site, if he don't have access to the authorized relay. He can't send mail while still having a perfectly usable SMTP relay at his

    • Other problems with SPF (Score:5, Interesting)

      by 0x0d0a ( 568518 ) on Friday January 09, 2004 @07:28AM (#7926898) Journal
      ...SPF technically wise sucks

      Agreed. I'm going to cut-and-paste the set of flaws I was talking about *last* time SPF came up on Slashdot:
      First, this is nothing more than an authentication system. It's designed to allow a server to authenticate itself as a trusted source for a domain's email. However, the designers chose to use DNS as a transport mechanism. Not a good idea. DNS is designed to be lightweight and low latency, not to be secure. It's pretty easy to spoof DNS responses. Plus, DNS data tends to get cached. All you need to do is spoof a response, the nameserver's cache is poisoned with false data, and the next N emails (until the cached data expires) are accepted as valid.

      Second, this system relies on having everyone implement such functionality. Spammers don't give a damn about return addresses, so they can send email with a from address at any domain. The annoying and ineffective attempts at stopping all open mail relays on the Internet illustrate the failure of this model. A security system that relies on correct implementation over the full Internet to function properly will not work in real life.

      Third, this fails to deal with throwaway domains. The authors waffle a bit about them, and finally come out and admit that more mechanisms are required. Dammit, if we had a good PKI trust-ranking system (which is the sort of thing that they are requiring to fix their failings) we wouldn't need this system at *all*, since we could simply sign email and have trust rankings for users.

      Enough about the bad design: other reasons I don't like it include:

      * The authors have made a decision to make it really annoying to send email from a machine, and have to work with your ISP just to have a mail server. There are plenty of more solid antispam proposed mechanisms that do not place restrictions on who runs what servers (pay-per-email or pay-per-initial-email, PKI systems). This is much more in line with the way the Internet works for most services.

      * There is a supposedly trusted authentication system being spread across the entire Internet over an insecure transport protocol.

      * DNS caching can make moving an SMTP server or setting up a new one take a significant amount of time.

      * IP-based auth isn't a great idea anyway, for a number of reasons. The authors claim that it isn't a huge issue, because IP spoofing is harder (I disagree -- things like Mobile IP have made it harder to *block* IP spoofing).

      * Users have no control over what gets blocked. If I *want* to receive email of a particular type, I can't. Two ISPs (sending and receiving) are the ones that determine what mail I can receive). This is perhaps acceptable within a company, but annoying and goes against traditional Internet structure.

      * It does nothing to avoid compromised end user machines.

      * It does nothing to deal with throwaway accounts.

      * It does nothing to deal with misconfigured servers.
      • Unfortunately you don't bother to say how your preferred solutions fix spam.

        Pay per email? Pay whom, precisely? The ISP? I've already paid them for my subscription. If that is included in a spammers account, their spam gets through. Pay the recipient? Why should I pay you to send you email that isn't spam? Would you give me the cash back? You say that SPF works against the way the internet works, well, the internet is a free-for-all, so why is paying per email NOT against the way the internet works
      • * The authors have made a decision to make it really annoying to send email from a machine, and have to work with your ISP just to have a mail server. There are plenty of more solid antispam proposed mechanisms that do not place restrictions on who runs what servers (pay-per-email or pay-per-initial-email, PKI systems). This is much more in line with the way the Internet works for most services.

        Less annoying then hundreds of SPAMs a week.

        * There is a supposedly trusted authentication system being spr

  • Dynamic IP addresses (Score:3, Informative)

    by njdj ( 458173 ) on Friday January 09, 2004 @05:17AM (#7926476)
    This is not going to work for domains that have dynamic IP addresses. Yet another reason we need to migrate to IPv6 and eliminate the need for dynamic IP addresses.

    • Re:Dynamic IP addresses (Score:4, Informative)

      by Motherfucking Shit ( 636021 ) on Friday January 09, 2004 @06:13AM (#7926640) Journal
      This is not going to work for domains that have dynamic IP addresses.
      Sure it is, you can specify CIDR notation within your SPF record. This lets you cover the pool of IP addresses that you (or your users) might be assigned. Check out AOL's TXT record:
      aol.com. 300 IN TXT "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/24 ip4:205.188.157.0/24 ip4:205.188.159.0/24 ip4:64.12.136.0/24 ip4:64.12.137.0/24 ip4:64.12.138.0/24 ptr:mx.aol.com -all"
      Instead of listing every IP address that a legitimate piece of AOL mail could possibly come from - which would be a slight bit bulky for DNS - they've specified a bunch of /24's ("class C's") where their SMTP servers reside.
    • This is not going to work for domains that have dynamic IP addresses.

      SPF lets you specify ranges in CIDR format, so you just need to include the IP pools that the hosts that actually send mail might end up in. Or just set them all to use the ISP's smarthosts and use their static IPs in your domain's SPF records. There's even a very nice wizard [pobox.com] to create your SPF records with and get a feel for what's possible.

  • I got SASL working fine on my private box and use it when on the road just fine to send mail while using generous people's no-wap access points. It's very helpful. I just had to set up a saslpasswd for the account.

    But I also have mail system at work with 25,000 user accounts. I need to get sendmail to auth through the same pam system-auth other services use (it's a complex mix of kerberos with fallback to ldap). A separate sasldb is just not going to cut it in that environment

    I think saslauthd is the ti

  • It does seem to work (Score:4, Informative)

    by Erik Hensema ( 12898 ) on Friday January 09, 2004 @06:01AM (#7926604) Homepage
    In an amazing coincidence I just implemented SPF filtering on my server yesterday.

    This is what I got:

    Jan 8 19:34:01 scrat sendmail[16839]: i08IY0ON016839: Milter: from=<larhondabeirne@aol.com>, reject=550 5.7.1 Command rejected
    Jan 9 05:34:47 scrat sendmail[16305]: i094YlON016305: Milter: from=<krbsnag2gs@aol.com>, reject=550 5.7.1 Command rejected
    Jan 9 08:59:45 scrat sendmail[25027]: i097xiON025027: Milter: from=<clairacree@aol.com>, reject=550 5.7.1 Command rejected

  • SPF && DYNDNS (Score:3, Interesting)

    by tacocat ( 527354 ) <tallison1 AT twmi DOT rr DOT com> on Friday January 09, 2004 @06:02AM (#7926610)

    Does anyone know how SPF can be managed via dynamice DNS type of DNS services?

    It seems to me that having my reverse DNS lookup containing my ISP's domain name rather than mine would help my server configuration. I have a problem with my DNS in that reverse lookups are resolved to a DNS entry, but it belongs to my ISP domain and not my domain name. This gets some people pissy, but I don't see it being worth spending $100 a month extra from my ISP.

    And if anyone even thinks about responding with, "Change your ISP" I'll beat them severly with a Windows CD. I don't have any alternative ISP's available. If someone would be willing to help pay the $200 monthly fees for any alternatives I would consider it.

    Would SPF help this problem? Would I actually be able to gain trust from others? Would DynDNS be able to accomodate this feature? (I'll have to ask them...)

    I think a lot of this falls back to a much simply question: Why do we have DHCP addresses on the internet anyways? They do not change. I think mine is about 9 months old. Others tell of greater than a year with the same IP address. I think it would actually help security if people where give static IP addresses. Then they would have to take care of it to ensure they don't act stupid.

    • I think a lot of this falls back to a much simply question: Why do we have DHCP addresses on the internet anyways? They do not change. I think mine is about 9 months old. Others tell of greater than a year with the same IP address. I think it would actually help security if people where give static IP addresses. Then they would have to take care of it to ensure they don't act stupid.

      The simple answer here is this: Limited amount of resources. The same reason we use Dynamic addresses, is the same reason

      • Re:SPF && DYNDNS (Score:3, Insightful)

        by Skjellifetti ( 561341 )
        ips are often assigned based on the network card's physical addr. Some cards have setup software that allows you to change this number. Try changing it, restart your dhcp client and see if the tcp/ip addr has changed. Set it back and see if you get your old tcp/ip addr back. RR in Columbus seems to work this way. When I have installed a new firewall, just moving the old network card to the new machine lets me keep the old tcp/ip addr.

  • Damni! "RMX" was such a cooler acronym! (Score:3, Informative)

    by autopr0n ( 534291 ) on Friday January 09, 2004 @08:20AM (#7927142) Homepage Journal
    Anyway, I hope register.com hurries the hell up and lets me add these to my domains. I've actually been getting a bunch "recipient not found" messages going to [random word]@[mydomain.com] (not autpr0n.com, either my personal domain) meaning someone is spamming and using forged address claming to be from my domain

    and for each bounced message, who knows how many are getting through. A friend of mine (an AOL user) actually had a spammer us his personal email address, and got not only a bunch of bounces, but angry emails and IMs.

    The sooner this goes into effect, the better. It'll probably be a long time before we can block all email that doesn't come from a domain with SPF, but hopefully soon we can get rid of emails that are explicitly not authorized. (like those claming to be from my servers...)

  • I see a problem here.... (Score:5, Insightful)

    by matth ( 22742 ) on Friday January 09, 2004 @08:28AM (#7927184) Homepage
    Question on this whole SPF thing.
    I'm interested in it but have a slight issue with it at the moment that
    I'd like to get resolved.

    My domain is: mydomain.com
    Customer A is traveling and is using his e-mail of joe@mydomain.com
    However, I do IP filtering on my mail server (not SASL AUTH), for my
    dial-up pools.
    When Customer A is at hotel he must use their mail server to send mail
    out, so his mail will be rejected because the hotel mail server isn't
    listed in mydomain.com's SPF txt list.

    You suggest running SASL AUTH as a work around for this, however in my
    experience this creates MORE of a spam problem then not using SPF..
    here's why:

    On a mail server with over 40,000 users it's relitively easy for someone
    with a password cracker to hammer away at common names like 'joe'
    'jeffp', etc and try to get some passwords. Once they have a
    username/password combo they can happily send e-mail out as that user
    through MY mail server, and I can't do anything about them. Doing IP
    filtering requires that they are on MY network to send mail through MY
    server, thus allowing me to terminate/prosecute/etc the person.
    • I'm not a networking expert (as everyone who corrects me will probably point out), but couldn't you do something like:

      1. Make the customers use Webmail or equivalent when traveling. The mail still originates with your servers.

      2. Make the customers VPN to your domain when traveling. The mail is then handled by your servers.

      AOL basically does the second, if you connect to them via another service (like AOL High Speed stuff).

      I know neither of those are as convenient as "free mail, anywhere, anytime, no q

    • Re:I see a problem here.... (Score:4, Interesting)

      by dozer ( 30790 ) on Friday January 09, 2004 @01:41PM (#7930747)
      Um, how about actually watching for cracking attempts? "My word, user jimj just tried to log in 100 times in less than 1 hour. Let's deny the IP address he's trying to log in from."

      As far as I can understand, your argument boils down to "I don't like SPF because my systems are hideously insecure, I'm cool with them being used as open relays, and I don't feel like being a competent sysadmin"?

  • AOL will likely remove these SPF records today (Score:5, Informative)

    by wayne ( 1579 ) <wayne@schlitt.net> on Friday January 09, 2004 @08:40AM (#7927250) Homepage Journal
    According to a message from Meng Weng Wong (the author of SPF), AOL will likely remove these SPF records today (Friday). There are still kinks that need to be worked out, and AOL doesn't like to make big changes like this to be permanent and/or last over the weekends until more testing has been done.

    See: this message on the SPF mailing list [gmane.org]

  • Breaks Forwarding (Score:4, Informative)

    by n-baxley ( 103975 ) * <nate@baxle y s . org> on Friday January 09, 2004 @10:28AM (#7928137) Homepage Journal
    The biggest problem I can see with this is that it breaks forwarding. I have several email addresses that I don't use anymore but that I still get email on. If I take the SPF people's recommendation and just remail it, I lose the sender information, or at least lose access to it when listing my emails. It would be nice if this could handel forwards as well.

Slashdot Top Deals

"Virtual" means never knowing where your next byte is coming from.

Close