SPF is a system that is used by a domain to prevent email spam by detecting if a sender is using email “spoofing.” Spoofing is when a sender is trying to falsify where their email originates from. An SPF record is a TXT-record in a Domain Name System (DNS). SPF records simply list all the servers that are allowed to send email from your domain.

The SPF record is made up of two main components: mechanisms and qualifiers. Think of the mechanism as a way to find IP addresses. Qualifiers are the action to be taken on email sent from the IP address fetched by the mechanism.

The four available actions for the qualifier are:

• + = Accept
• - = Reject
• ? = Neutral
• ~ = Soft Fail (meaning accept and mark as spam)

Here is an example of an SPF record:

v=spf1 ipv4:207.97.227.239  -all

This allow emails from the given IP address and reject the rest.

The Mail Transfer Agent (MTA) that transfers email from server to server uses this DNS information to check on the validity of a given IP address/domain to see if it is allowed or not. Sometimes your email will put a suspect email into your spam folder, and sometimes it will reject it completely. The SPF check happens before the message body is received, so you will not see a rejected email.

To learn more about SPF-records, take a look at the Wikipedia-page and RFC 4408.

• The topmost bar is for all-day events.
• All syncing happens via iCal. Hence you may need iCal running for Blotter to fully sync.

A few days Jacob Appelbaum, one of Tor Project’s core members sent out a message to the Tor mailing list, urging for help after an increased crackdown in Iran. This can be seen in the image below.

We wanted to help out, so we reached out to cloud vendors to see if they were willing to help. Luckily they were. Thanks to the kind contribution of servers from CityCloud, we now have five Tor-relays up and running in Sweden (with obfsproxy).

We also expect to soon have more Tor-relays up and running in Switzerland on CloudSigma‘s network.

This is why we are extremely excited here at WireLoad to unveil something we’ve been working on for almost a year — the brand new YippieMove. The new version is a complete redesign, from the logo to the user interface and back-end. With the new YippieMove, it has never been easier to move email data across email accounts and services, and not to mention in such style. YippieMove is using our reliable email migration back-end which can swiftly push data across email providers.

If you’re looking for a scalable turn-key solution for migrating data, YippieMove is the answer. Our current clients range from small individual users, to top Google Apps-resellers, to university clients who are migrating their entire student body between providers. Nobody is too big or too small for YippieMove.

So what’s new in the new release? Here’s a list of some of the awesome new features.

• An extensive visual overhaul of the user interface.
• A new credit-system that gives you more flexibilities and better discounts.
• A completely rewritten user interface based on our soon-to-be-launched API.
• A new status page that gives you better insight into your email transfer and mailboxes.
• A re-designed batch-interface with better CSV-support.

But don’t take our word for how great the new YippieMove is. Here’s what Crisantos Hajibrahim of ViWo, one of the leading Google Apps resellers and nominated to Google’s Partner of the year, had to say about YippieMove:

There are many products in the market place that can do email migration, but what really sets YippieMove apart is the reliability, dedication to relationship building and support. YippieMove simply makes our lives easier. We can focus on our customers, and not worry about email migrations. This is why ViWo continually works with YippieMove.

Screenshots

Visit the brand new YippieMove.

The 1.5 update of Quiet is primarily about improving performance and adding more compliance with Apple’s Mac App Store regulations (as a result the ‘Hide Dock’ feature had to be removed). We apologize about having to remove this feature, but we don’t make the rules.

• The ‘Hide Dock’ option has been removed.
• Focus out is now more battery efficient and CPU friendly.
• Fade To Black and Wallpaper options fade in more smoothly.
• Resolved a graphical corruption issue with Focus Out.
• Restores Snow Leopard support

Similar to both Dovecot and Microsoft Exchange, Mirapoint Message Server also support logging into users’ accounts via the admin account by using a modified username-string.

The username string Mirapoint Message Server is using for admin-authentication looks as follows:

#user@example.com#AdminUserName#

Hence, if your admin-account is ‘jdoe’, and you’re trying to access the account ‘jsmith@example.com’, your string would look like this:

#jsmith@example.com#jdoe#

Before you move forward with the migration, make sure you can login using this method (the custom username-string mentioned above, along with the admin-password) using a desktop client, like Thunderbird, or using OpenSSL as we did in the Dovecot-guide.

Once you’ve verified that you can login, you can proceed with your YippieMove e-mail migration. You can either do a single-migration, or use the batch-migration tool.

If you got any questions, please let us know either by contacting the support or comment below.

Now with 2.0.1 released, we’ve submitted an update that resolves the issue with subscription calendars.

We sincerely apologize for the inconvenience that these bugs may have caused.

There is however a very good reason why we do not accept PayPal payment: it’s simply not a good experience. It’s not good for our customers, and it’s not good for us. PayPal has a well established record of mistreating its customers with little or no recourse. Once PayPal has arbitrarily frozen the money of a customer, whether it’s a merchant or private user, they provide virtually no recourse. There is no-one you can call, they are not regulated like a bank, and there is no ombudsman. Your money is simply beyond your reach, at the mercy of a few moody customer service reps.

That’s just not an experience we want to provide to our users. Nor, frankly, one we can accept for our own business.

If this only happened once, one could argue that it was an honest mistake from PayPal’s end. However, that’s hardly the case. Since you are the smart individuals that we think you are, don’t just take our word for it. Here’s some further reading:

• Stop being greedy people who shut down organizations to help the poor.
• Paypal’s Ridiculous Business Practices
• Diaspora: Paypal blocked our account and is preventing donations
• I need my money but PayPal has frozen me out
• PayPal Freezes $750K in MineCraft Dev’s Account
• Cryptome: PayPal a ‘liar, cheat and a thug’
• How PayPal screws open source projects
• PayPal disgraces itself, cuts off FreeNet
• The X.org folks lost $5k to PayPal

Those are just a few examples. There are plenty of more examples to find and we haven’t even mentioned the whole situation with PayPal’s blockage of WikiLeaks.

We think that our customers deserve the best. We will continue to look for new payment options and we follow the development of modern payment services like Dwolla, Stripe and Bitcoin with great interest. Unfortunately PayPal is just not an option for a customer friendly company.

The concept of dual delivery isn’t very hard to wrap your head around, but how does it work? When reading forums, some people are confused about this. Some people think that it is sufficient to have two servers with the same priority level in the MX-record. This is not the case. Simply having two MX-records with the same priority will load balance between the two, but not deliver to both.

In order to set up dual delivery, you need to have a primary email server relay the messages to the secondary server. How to configure this varies a lot between different email servers and solutions. For instance, the instructions for setting this up with Google Apps can be found here.

Now that you understand how this works and how it is configured, it may be a good time to discuss the pros and cons. The obvious benefit with using dual delivery is redundancy. You get a second copy of all incoming messages. The drawback however, is that this only solves the issue of inbound emails. It does not solve the issue of organizing the mailboxes. If a user is using the secondary server, his folder-structure, organization of messages, and read/unread status will not get propagated between the two servers. It is possible with certain setups to accomplish this too, but that’s not within the scope of dual delivery per se.

Please comment below if you have any questions, and as always, check out YippieMove for all your email migration needs.

Want to learn more about email and email systems? Learn more in The Email School.