Slashdot Mirror

Second, configure SPF records for all of your domains. It may not help today, but an increasing number of mailservers are rejecting mail that fails SPF validation.

Third, learn to love your access file. Mine contains lines like:

erin@honeypot.net "550 This account was spoofed by some jackass spammer. It doesn't exist and never has."
michelle@honeypot.net "550 This account was spoofed by some jackass spammer. It doesn't exist and never has."
mike@honeypot.net "550 This account was spoofed by some jackass spammer. It doesn't exist and never has."
mikey@honeypot.net "550 This account was spoofed by some jackass spammer. It doesn't exist and never has."
misha@honeypot.net "550 This account was spoofed by some jackass spammer. It doesn't exist and never has."
richard@honeypot.net "550 This account was spoofed by some jackass spammer. It doesn't exist and never has."

If you don't flag anything that doesn't match as a fail (-all at the end), then you won't see much difference. It also depends on the server receiving such spoofed emails actually doing checks against SPF records.

Most domains out there are defaulting to "neutral" or "softfail" as the default in their SPF records for now until sites that do mail forwarding or web mail (preserving the original envelope FROM address) implement SRS. If you have fairly solid control over where mail from your domain comes from, then you can go ahead and set the default to "fail".

That's a bit of a stretch. Why would you block TXT records? Also, TCP is a perfectly valid transport for DNS and by default most resolvers will use it for zone transfers and any other application where the expected response will be larger than 512 bytes. As a firewall admin wherever I've allowed incoming DNS over UDP, I allow DNS over TCP as well. Not doing so breaks DNS.

Its parsing is too complex
The parsing can loop forever

I don't think this is a showstopper, I mean HTML seems to be pretty popular.

It will increase DNS scaning as spamers hunt for broken SPF records

So?

Its too complex to be implimented inside the MTA where it needs to be done
It can't be properly parsed in sendmail

I guess you've got me there.

ISO 8839 8859 59-15 utf-8 issues for domain names may kill some dns servers

What does this have to do with SPF? Those DNS servers will die regardless.

Its a step in the right direction but its the wrong step.

If you don't like it, propose something. Then get used to taking what you're dishing out.

Yes, it is very flexible, with many other alternatives.

like digital signing with a hidden key whose pair is regestered in the DNS?

This isn't an option, but there are many alternatives.

Firstly, you must own a domain name. If you don't have a domain name and you're sending email using someone else's domain name, you need to contact the adminstrator for the domain you are using.

Let's assume you have a domain name, you're running your own mail server, and a dynamic IP number assigned by your ISP. To make this work, you're already publishing DNS records for your domain that get updated every time your IP number changes. If your server transmits your mail, SPF is much easier than what you're already forced to do... just publish "v=spf1 mx -all", meaning that all messages come from your server.

Suppose you're not really running your own server. Maybe someone else receives for you and forwards the messages. This is common with "vanity domains" (a name specific to you). Maybe when you transmit, you relay through your ISP. In that case, you could use the "include" type if your ISP publishes a SPF record, or if you know the IPs of their servers you could specify their IP number, or if you only know the netblock assigned to your ISP, you could "ip4" with a mask for all your ISP's IP range.

Or maybe you transmit directly from your dynamic IP number without relaying through your ISP. Again, SPF can handle that too... as long as you know the range of IPs your ISP uses to assign for you. Just use the "ip4" type with a mask (or mulitple "ip4" if you ISP assigns from more than one pool of IP numbers).

Whatever you do, you can specify additional methods to cover the other possible cases, so that your messages won't get rejected.

IANAL, but the text of this agreement seems to indicate that this implementation license applies to any products that "implement and are compliant with" Sender ID (section 1.2), and that Microsoft may subsequently terminate the license (section 3).

Anybody familiar with this? Is there a RFC for Sender ID?

The one horrible thing with today's mail protocols is that you can pretend you are someone else. It would have been so easy to add a handshake in there: So you claim you are, af62co@spamking.com, ok, pls verify that, before I even think of showing your mail to the recipient.

I may be missing something here, but I do not know what. Anyone who can tell me where I go wrong?

His point is that: why doesn't the compiler/linker/environment help find the errors that programmers make?

He questions why gcc only issues warnings in cases where the generated code can't possibly be right. He goes a little too far by suggesting that we should just plug a GC wrapper into malloc/free (this changes the memory footprint of the program) but his ideas are sound.

Very few programmers have been railing about the inherent danger of the programming environment, and the total lack of help from the compiler. Of course *I* was one of them:

http://bstring.sf.net/

(The bsafe module overrides the most unsafe string function calls, thus forcing the developer to use the safe alternatives.)

http://www.pobox.com/~qed/userInput.html

(A way of using strong typing as a mechanism for duplicating the functionality of "tainting".)

The hard problem is making sure you're really always going to try to send mail from the IP addresses belonging to your domain, which may require you to build SSL-encrypted SMTP submission into your mail server if you don't have that already. But that's a usually good thing to have.

The hard problem is making sure you're really always going to try to send mail from the IP addresses belonging to your domain, which may require you to build SSL-encrypted SMTP submission into your mail server if you don't have that already. But that's a usually good thing to have.

Or use SPF since AOL have been publishing SPF records for a while now. (I believe SpamAssassin 3.00 supports SPF out of the box).

I believe it would be both mroe effective and cheaper in the end to simply fix smtp to the point where this is no longer a possibility.

Some info on how that should be done and why..

Sender Policy Framework
Why SPF?
Authentication Is Key To Fighting Spam
Spammy issues

This solves a lot more then the 'zombie' issue, and has to be done anyway, why not do it now and fix multiple problems at the same time instead of putting up fees for all kinds of things.

I agree that retransmitting someone else's message to a new recipient will be seriously problematic in SPF land and will break ".forward" files all over the world.

Until a millisecond after the user replaces

user@domain.tld

...in his .forward file with...

|/usr/bin/srs user@domain.tld

...and the sysadmin inserts these two lines into /etc/aliases (after installing Mail::SRS from CPAN):

srs0: "|/usr/bin/srs -reverse"
srs1: "|/usr/bin/srs -reverse"

It's documented. And amply so, too.

Rick Moen
rick@linuxmafia.com

There is a way around that, though, and a rather easy one to implement depending on the mail server involved. Patches for sender address rewriting are still being developed for different MTAs, but that plus the lag of getting ISPs involved are the two major reasons why SPF isn't in full force yet.

Besides, the article does reference SPF, though indirectly. That and M$'s Caller-ID are the only things that I know of that realistically authenticate by IP address, and they've just recently merged.

Several large ISPs are backing SPF. I even noticed my ISP, Verizon, who tend to be quite lazy and stupid when it comes to spam (and other things), have added an SPF record.

If you read the linked email and the replies to it, you will find that the linked post is a troll. For real information about SPF, visit spf.pobox.com.

I've never heard of any IPS giving 1GB away per email accounts and you can actually leave the emails on their server. AND, where are the other features proposed by gmail, like the super-quick search option?

Many of us are consider a gmail account with 1GB! Once you start using your gmail accounts and that your friends are aware of your new email address, next time the network of your IPS goes down -- you can leave right away without having to worry that you might loose some emails, etc.

How many people stays with their ISP because they don't want to loose their email address, even if their IPS's network sucks?

And, when will my email address be portable from an IPS to another one? I doubt this will ever come, and until then... This is why I *never* used the free email address from my IPS, thanx to PObox.com -- they forward my email anywhere I wish and as of a few days ago, even to my gmail account!!!

I have no problem with sending email to AOL from our non-megacorp servers. Of course, we've never sent stuff to AOL that was classified as "bulk email", and we have taken a few moments to incorporate Sender Policy Framework records into our DNS, in keeping with AOL's stated policy on SPF and "whitelisting", so your mileage may vary.

SPF is the answer. Unfortunately, nobody's discovered what the question is to go with that answer

I'll take Spam Solutions for one hundred, please. Question : what FUSSP is an anti-forgery technique that doesn't address the underlying problem, breaks forwarding and is simply defeated anyway by using the null envelope sender?

Ironically, these and other reasons may be an argument that SPF should be adopted

Why is it the answer? If M$ created a piece of software that broke a standard they would get lynched by a mob of \.'ers but when something like SPF does it, it's OMG SO COOL

Also cue the spelling zealots!

P.S. SPF is the answer!

And que the SPF-Zelots saying SPF is the answer!

I'm glad that they haven't jumped in headfirst, I can't imagine how they could enforce such a list right now with so much spam coming from outside of the United States and from unknowing zombie PCs within the US. If they did create a list it would place an expectation in the public eye that the US government can enforce it, when it obviously (to us slashdot readers) cannot.

Like it or not, we need to come up with more clever hardware or software solutions like Yahoo's "Domain Keys", Meng Weng Wong's SPF (Sender Policy Framework), or god forbid, Microsoft's Caller ID for E-mail.

1. ISPs (and any other business that gives a workstation a "real" IP address) need to block egress port 25. Comcast is going to be doing this soon, others should soon follow suit. This plugs the zombies.
2. IP addresses that continue to send spam will be blacklisted. With the zombies effectively out of the loop this will become easier (albeit never quite perfect).
3. SPF and other authentication schemes need to be adopted to prevent "spoofing" and so called "Joe jobs".
4. E-mail providers (including small companies) need to deploy mature e-mail systems for their users. In 1995 it was fine to accept e-mail from anyone on port 25, with no authentication and no encryption. In 2004, remote clients need to have an SSL connection available (both for sending mail and accessing inboxes), and must require authentication before accepting initial mail submission (SMTP+TLS+AUTH). Not only is this more secure, but it also addresses the issues always raised by blocking egress port 25 and deploying SPF.

Appendix:
SMTP+TLS+AUTH is not that tough, no whining. All modern mail clients support it, on all platforms. There is a little bit of work to do on the server end, but that's what you pay your ISP (or IT department) for:

• postfix
• sendmail
• exchange
• qmail

I don't use MAPS, but do blacklist residental Internet connections, so when people in your situation send me email (as the postmaster for a domain diluged with spam), I offer to whitelist them until I get SPF-based whitelisting implemented. If I am the first to add that technology to sendmail, you'll see a post on sendmail newsgroup.

I agree that it will not be easy to make everyone switch at once, but that is true for many of the proposed solutions.

SPF, for instance, fights forgery, which happens to make it easier to identify the real origins of spam. Finding the real origins of spam makes it easier to make policy decisions for filtering and blocking common sources of spam.

This can easily be rolled out as needed or desired and doesn't need to be rolled out everywhere for it to start being effective right away. "Difficult" doesn't do justice to something that replaces SMTP outright.

Why do ISPs risk common carrier status?

ISPs may be considered common carriers in your locale, but the laws and regulations in the USA do not consider ISPs to be common carriers. Other locales may vary as well.

Filtering to suppress an undesirable (to them) form of traffic kinda contradicts that and would turn them more into the equivalent of a content provider.

Spam is about consent, not content.

Under SPF, that's simple - you list all servers that can handle your domain's mail in the SPF record. Take a look at the SPF home page for more details, including a link to a wizard to "calculate" the proper SPF DNS entry for situations such as yours. You should be using some form of certification of who you are when sending mail via any server, so that you can tell people "that wasn't me!" when someone forges a message from you. SPF is simply one method to aid in that.

That said, I don't like the MS scheme - it's yet another demand on bandwidth that doesn't provide the benefits claimed in any way better than less intensive methods (like SPF).

The MicroSoft Caller-ID/SPF merger proposals say that SPF records will be honored, so you can publish them without fear of losing support.

So, go ahead and publish SPF records.

MicroSoft supporting SPF records is a really smart move. Last week, I posted results of a survey of 1.3 million email domain names to the IETF MARID mailing list. Now that I'm back from the MARID meeting, I just finished a survey of Caller-ID records. There appears to be about a factor of 500-1000 more domains that have published SPF exclusively than Caller-ID exclusively and only a tiny fraction of the 1.3 million domains have published Caller-ID records. In short, MicroSoft isn't changing to support SPF records because they are better (I think they are), but because it is an acknowledgement that MicroSoft's Caller-ID hasn't caught on.

Meng Weng Wong (the SPF author) and MicroSoft are still discussing how exactly this merger will work on. I personally don't see any reason to support XML right away. MicroSoft has not come out with a single concrete extention that can't be done with SPF already.

I also think that there are alternatives to the complex Caller-ID algorithm and that doesn't require every Ezmlm and other mailing lists to upgrade their software. From the research that I've done (and yes, this is something I have really researched), there appears to be far more mailing lists broken by MS's Caller-ID system than email forwarders broken by SPF.

(I'm the author of libspf-alt and the maintainer of the trusted-forwarder global whitelist. So, now you know why I have researched this stuff so much.)

<Conspiracy>Funny, that's exactly the business that SPF's author (pobox.com) is in.</Consipiracy>

It'd be a whole lot easier to deal with Comcast's crap if they'd simply publish SPF records for their mailservers.

Anyone who had no interest in communicating with Comcast client boxes could just drop non-SPF-validated traffic with no further ado, without having to track Comcast's use of "client," "client1," "client2," et cetera ad nauseam.

Other hosts could whitelist individual servers if they needed to/chose to.

SPF (Sender Permited From) is conceptually very similar to the MO mail outbound idea you're proposing. The syntax isn't very MX-like though. But as to having it XML - please no! I can't ever imagine having DNS info stored in XML, it's just bloated featuritis at its worst. It will mean having to upgrade MTAs and nameservers, and all the config rewriting, for no real immediate benefit.

See spf.pobox.com for more info on the SPF spec. God knows what it will look like after the changes they're working on with MS. Looks like changes to SMTP as well as DNS. Seeing as many people aren't even bothering to have reverse IP set up right, this could be a long time coming.

• fast automated blacklisting using spamtraps and attack detectors
  
• simple reputation systems based on factors such as age of domain according to whois
  
• email profile of domain, eg. "too many unknown recipients"
  
• call-back tests to see if the sender domain is able to receive mail.
  
• the reputation system can advise a receiving MTA to defer or reject.
  
• legal methods following the paper trail of who paid for the domain.

here (it's linked in the text you quoted from FFS).

True, but that's a solveable problem.

I find the broken forwarding to be the biggest problem with SPF. -- Their solution SRS, rewriting the Envelope addresses so that the middleman then handles all the bounces seem like a definite kludge. (You can read about it here

As someone who provides hosting for small companies and usually uses /etc/mail/virtusertable to forward mail for customer domains, I don't want my setup/setup tools broken by having to implement a more complex mechanism and in turn have a higher server load handling bounced messages when a client's mail box is filled.

While I haven't read the DomainKeys proposal, it has occurred to me before that a variation on SPF with encryption could be implemented without having to extend the ESMTP protocol. TTBOMK (To the Best of My Knowledge) ESMTP allows you to send parameters following the "MAIL FROM" command and these parameters would be preserved as part of the message envelope when forwarding. It would seem to me that an PGP/GPG, private key, encrypted string sent as a parameter would allow updated MTAs to verify the original source by decrypting the string with the orignating servers published public key. How does one publish their public key? Simple, use the TXT record in DNS (similiar to SPF's use of DNS). At the same time, this shouldn't in anyway break compatability with receiving SMTP servers that don't recognise the new parameter.

While I haven't RTFA, this has been on my mind for a while, as a "better than SPF" solution and I'm sharing it here. How do you think it stacks up to SPF/DomainKeys?

• If the receiver does not check SPF, then no mail is rejected and forwarding is not broken.
• If the receiver does check SPF, but doesn't use any forwarders, then forwarding is not broken.
• If the receiver does check SPF, but uses only forwarders that implement SRS, then forwarding is not broken.
• If the receiver does check SPF and uses a non-SRS forwarder, but uses a whitelist to avoid rejecting mail from that forwarder, then forwarding is not broken.
• If the receiver check SPF and uses a non-SRS forwarder, but configures their MTA to reject mail from that forwarder, then their incompetence will result in rejected mail. How is this the fault of SPF?

You've gotta be kidding me. SPF requires SRS for folks who use forwarding services. This is all over the website. It's also pretty clear from what I've seen that *all* the good solutions to the forged email problem will break forwarding as we do it today. That's just the way it goes. We can't afford to be as trusting today as we could when email was invented. It sucks, but it's reality.

Yes, folks need to implement things properly. That's largely why SPF has different fail modes, so you can slowly phase it in. As it gains more momentum, the folks who run mail servers will have to play along in order to have their systems reap the rewards of non-spoofed email. Welcome to the wonderful wide world of cooperation. There's this thing called the internet that works largely because of this. Perhaps you've heard of it?

SPF tries to assure the sender of the message (MAIL FROM, return-path, whatever you want to call it) is legitimate. DomainKeys can be used to assure the author of the message (From: header) is legitimate.

I quote this from the very top of the SPF FAQ itself:

"Protecting authorship information is an important goal. However, the technical issues associated with protecting the "From:" header are much more numerous and challenging. The best way to protect the header "From:" is by using a cryptographic signature such as S/MIME, PGP, or (when it is released) Yahoo DomainKeys."

You want to implement both. SPF detects envelope forgeries before you have wasted much bandwidth. You can then use right hand side blacklists on sender domains. Yes, spammers too are adopting SPF. This is OK - those who like spam have something other than instinct to warn them when they are dealing with a scammer instead of a spammer. Those who hate spam can ignore it more efficiently.

Domain Keys validates the message headers. It protects you against forgeries by users in the same domain - e.g. a spammer on yahoo forging an innocent party on yahoo. SPF can also detect envelope sender forgeries from the same domain in conjuction with SES (Signed Envelope Sender) - which adds a crypto cookie to the local part.

You should implement SPF first. It is simpler, and eliminates most forgeries before SMTP DATA. SPF requires sepcial consideration for forwarders (SRS - Sender Rewriting Scheme) or whitelisting.

DK is a good addon for large ISP domains like yahoo and aol, but is broken by forwarders or mail processing tools that modify the body. For instance, my DSPAM bayesian filter adds "tags" to messages.

Yes it breaks forwarding but they have ways to make it seamless for users by using a
Sender Rewriting Scheme

other than doing relay-based signing of the messages to provide the sender verification.

SPF's handling of relays is broken:

But that breaks forwarding!

Yes, it does. You'll have to switch from forwarding, where the envelope sender is preserved, to remailing, where the envelope sender is changed. But don't worry, we're working on providing SRS patches for the four major opensource MTAs, so that when you upgrade to an SPF-aware version, this problem will be solved also.

If DomainKeys takes care of that, I'd choose it over SPF in a heartbeat.

Yes there is. It's called SPF.

Maybe we should seriously consider to embrace SPF(RFC Draft)
It perhaps won't stop all spam, but it will make it easy to verify weter a mail comes from where it claims to. That makes 2 good things.
1. You don't want mail from anyone that forges their origin, so those(spams/viruses) you can filter away.
2. Spammers will be forced to use their true origin, and thus much easier to identify.

Maybe we should seriously consider to embrace SPF(RFC Draft)
It perhaps won't stop all spam, but it will make it easy to verify weter a mail comes from where it claims to. That makes 2 good things.
1. You don't want mail from anyone that forges their origin, so those(spams/viruses) you can filter away.
2. Spammers will be forced to use their true origin, and thus much easier to identify.

I live in Spain, and yes, I use that ISP, because they were the first to offer ADSL here. Changing now would be a not so fun thing, but I might when a better ISP comes out. The others ain't better, and right now I have static IP for free, which would be an added fee if I change to another ISP.

I do run my own MTA and yes, I have a SPFrecord in my DNS entries.

Now the fun thing, do you where most of the spam I get comes from? Residential DSL/cable computers in USA.

No, because there are ways of verifying where the email came from.

Sender Policy Framework

May I suggest you check out the Sender Policy Framework website? It could help you by cutting down on the amount of bounces you recieve when you are "Joe-jobbed".

Check out http://www.pobox.com/

They've been around for about 10 years.

Hybrid cars have enermous fuel economy. Many provide the same acceleration and top speed (almost) as current cars. Not a hot rod, but a "regular" car.

This becomes a problem for people that tow stuff. Even with the improved fuel economy, it's cheaper to drive your SUV every day of the year than buy 2 cars (one for towing, one for everyday driving).

Most people, however, will save money in the long run with these vehicles. I get the feeling that most people are waiting to see how durable they are before they buy one.

• SPF is the natural counterpart of the MX list. It should have been in SMTP and DNS from the beginning.
  
  
• SPF is a voluntary system. If you do not participate, email will continue to work as before.
  
  
• SPF is free and open standard, an extension to SMTP.
  
  
• SPF expects to see support in SpamAssassin v2.70, Sophos, Symantec, BrightMail, MailArmory.com, MailFrontier.com, Declude Junkmail,, and others.
  
  
• SPF has plugins available in Postfix, Exim, Qmail, and Sendmail.
  
  
• SPF is aimed as much at worms and viruses as it is at spam.
  
  
• SPF is a complement to other antispam systems. It strengthens and improves them, and it makes new approaches possible. For example, domain-name blacklists and fine-grained reputation systems.
  
  
• SPF improves the veracity of sender addresses. Sender forgery is the moral equivalent of the open relay. SPF solves that problem.
  
  
• SPF is a permanent solution: after it has been
  installed, you don't have to update your content filters, or keep doing challenge-response. Each domain is responsible for publishing and maintaining its own SPF records, but that
  not much of a burden at all.
  
  
• SPF is being presented to the IETF for RFC consideration.
  
  
• SPF is designed to protect the envelope sender address, the return-path, where bounces go. It can also be used to protect the header "From:" address with some added complexity. If you are not confident of the difference, you will find RFC2821 and RFC2822 enlightening. Protecting the headers is inherently more challenging, because spammers are very good at forging headers, and you have to carefully choose between Sender, From, Resent-Sender, and Resent-From; it's a can of worms.
  
  
• Because SPF protects the return-path, users protected by SPF will stop getting bounces for messages they didn't send --- for example, "Your system sent us a virus".