All the operations available in the API are segregated into one of two sections, the mailbox (user) side and the admin side. The problem was that the Zimbra client only had implementations for the user set of APIs, and I needed to interface with the admin side of things.

So I went back to Google, and this time stumbled upon this great piece of work done by the folks running this website here. These folks must have been in the same boat as me a while back, and they actually managed to roll out their own WSDL for the admin api. Awesome! I finally had something concrete to work with. I quickly downloaded the wsdl and pointed CXF’s wsdl2java at it. Alas, it wasn’t that easy. The folks who wrote this seem to be Rubyists, and even though they claim it works with their Ruby client builder script, none of the Java implementations agreed with them.

So I fired up Eclipse, and had to apply a bunch of fixes, most of them related to namespaces and element ordering, before I had a file that validated perfectly. I also added a couple more operations that I thought I would need while I was at it. Note that all available operations still haven’t been implemented. If you do improve on it, please report back so I can update the file and others could benefit as well. This file has been tested to work with ZCS 6 and 7.

So there you have it folks, without any further ado, I present the elusive Java compliant WSDL for Zimbra’s SOAP API.

You can download the WSDL file here.

Last time I checked Java 6′s wsimport and wsgen were still complaining about something in the file, so I also zipped up the proxy client stubs generated by CXF 2.5, which can be downloaded here.

Android Market's Exponential Growth

If your current device doesn’t support an app you would like to purchase, but you would like to get it anyway, say because you plan to upgrade in the near future, you could still get the app from the online store at this link: https://market.android.com/details?feature=banne­r&id=apps_timed_promotion

Here is the list of fire sale apps for 6/12/2011:

1. SoundHound
2. Asphalt 6: Adrenaline HD
3. Minecraft – Pocket Edition (yep!)
4. SwiftKey X Keyboard
5. Endomondo Sports Tracker PRO
6. Great Little War Game
7. SketchBook Mobile
8. Fieldrunners HD
9. Color & Draw for kids: phone ed
10. Paper Camera

[Show as slideshow]

Also check out how this baby reboots in under 20 seconds:

So who is hoping to find one of these under the Christmas tree? Stay tuned for our next post where we rip it apart and apply some quality thermal paste to keep it running cool..

Prerequisites:

• I use the Eclipse IDE but any IDE of your choice should suffice as long as you know your way around.
• Download Spring 3 from here and download CXF 2.5 from here.
• Create a working install of Tomcat in your IDE or standalone.
• Intermediate working knowledge of Java is assumed.

Project Setup:

• Create a new Dynamic Web project in Eclipse.
• Add the following JARs from your Spring and CXF downloads into the lib folder:

spring-asm-3.0.6.RELEASE.jar
spring-beans-3.0.6.RELEASE.jar
spring-context-3.0.6.RELEASE.jar
spring-context-support-3.0.6.RELEASE.jar
spring-core-3.0.6.RELEASE.jar
spring-web-3.0.6.RELEASE.jar
commons-logging-1.1.1.jar
wsdl4j-1.6.2.jar
wss4j-1.6.3.jar
xml-resolver-1.2.jar
xmlschema-core-2.0.1.jar
xmlsec-1.4.5.jar
jaxrpc.jar
saaj.jar
saaj-api-1.3.jar
cxf-2.5.0.jar
bcprov-jdk16-146.jar
serializer-2.7.1.jar
xalan-2.7.1.jar
dom4j-1.6.1.jar

When creating web services, two approaches are possible: Contract-first and Contract-last. In contract-first, you define the service contract in WSDL (Web Service Definition Language) first, and then implement your service to the contract. This approach is better suited for newer projects. However, since the project I was working on already had the Java code written, the contract-last approach was a better choice, which is also what I will be explaining here.

The Server:

First up is our Java class, GreetingService. The service defines a single method, greet. It accepts a username and returns a greeting to the caller as a String (I know, I apologize for my lack of imagination).

package test;

import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebResult;
import javax.jws.WebService;

/**
 *
 * @author JD
 *
 */
@WebService(name = "GreetingService", targetNamespace = "http://test/")
public class GreetingService {

	@WebMethod
	public @WebResult(name = "greeting")
	String greet(@WebParam(name = "user") String user) {
		return "Hi there, " + user + "!";
	}

}

As you can see, this is a POJO with some annotations sprinkled in. The only required annotation would be @WebService.
Everything else simply assists in generating cleaner WSDL. For example, without the @WebParam annotation, the names of method arguments would be replaced with arg0, etc, making life a little difficult for a client.

Next up is our Spring configuration file, which will contain instructions for CXF to expose our service as a web service. Save this as a file named cxfContext.xml and put it in the WEB-INF directory.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:jaxws="http://cxf.apache.org/jaxws"
	xmlns:soap="http://cxf.apache.org/bindings/soap" xmlns:cxf="http://cxf.apache.org/core"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
         http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
         http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd">

	<!-- Interceptors -->
	<bean id="logIn" class="org.apache.cxf.interceptor.LoggingInInterceptor" />
	<bean id="logOut" class="org.apache.cxf.interceptor.LoggingOutInterceptor" />
	<!-- SAAJ Interceptor needs to be explicitly declared only in CXF 2.0.x -->
	<bean id="saajIn" class="org.apache.cxf.binding.soap.saaj.SAAJInInterceptor" />
	<bean id="wss4jIn" class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
		<constructor-arg>
			<map>
				<entry key="action" value="UsernameToken Timestamp" />
				<entry key="passwordType" value="PasswordText" />
			</map>
		</constructor-arg>
	</bean>

	<!-- The CXF Bus -->
	<cxf:bus>
		<cxf:features>
			<cxf:logging />
		</cxf:features>

		<cxf:properties>
			<entry key="ws-security.validate.token" value="false" />
			<entry key="ws-security.ut.no-callbacks" value="true" />
			<entry key="ws-security.ut.validator" value="test.UTValidator" />
		</cxf:properties>

		<cxf:inInterceptors>
			<ref bean="logIn" />
		</cxf:inInterceptors>
		<cxf:outInterceptors>
			<ref bean="logOut" />
		</cxf:outInterceptors>
		<cxf:inFaultInterceptors>
			<ref bean="logIn" />
		</cxf:inFaultInterceptors>
		<cxf:outFaultInterceptors>
			<ref bean="logOut" />
		</cxf:outFaultInterceptors>
	</cxf:bus>

	<!-- End points -->
	<jaxws:endpoint id="greeter" serviceName="GreetingService"
		implementor="test.GreetingService" address="/">
		<!-- wsdlLocation="WEB-INF/wsdl/library.wsdl" This will be generated automcatically
			when not specified -->
		<jaxws:inInterceptors>
			<ref bean="saajIn" />
			<ref bean="wss4jIn" />
		</jaxws:inInterceptors>
	</jaxws:endpoint>

</beans>

Lines 10 – 21 define the required interceptors for implementing WS-Security via the WSS4JInInterceptor and for logging. Line 50 defines the end point. Details on the attributes can be found here Notice how everything can be configured in a very Spring-like way thanks to the custom namespaces. Also note how common properties for all endpoints, such as logging interceptors and properties can be defined in the bus and don’t have to be repeated for each endpoint.

The

<cxf:properties>

element specifies a set of properties for the bus. Here we are saying we will be handling authentication ourselves, via ws-security.ut.validator key in the UTValidator class, and that no password callback handlers are required by setting ws-security.validate.token to true. If you use a different password scheme other than PasswordText, like PasswordDigest, you would have to set the plain text password from the digest in the password callback class. Note that the properties can also be overridden per endpoint using the

<jaxws:properties>

child element of

<jaxws:endpoint>

.

The authentication method we have chosen here is UserNameToken, which validates a username and password provided by the client, and Timestamp. While this is sufficient for development and testing, this needs to be beefed up by either encrypting the transport(https) or by using security tokens in production.

The UTValidator is simply a subclass of CXF’s UsernameTokenValdator, and overrides the verifyPlaintextPassword method to provide custom authentication. In a real world application, an authentication service such as one that validates the credentials provided against a directory such as LDAP can be used. If validation fails, this method must throw a WSSecurityException with the error code (the first constructor argument) set as WSSecurityException.FAILURE.

package test;

import org.apache.ws.security.WSSecurityException;
import org.apache.ws.security.handler.RequestData;
import org.apache.ws.security.message.token.UsernameToken;
import org.apache.ws.security.validate.UsernameTokenValidator;

public class UTValidator extends UsernameTokenValidator {

	@Override
	protected void verifyPlaintextPassword(UsernameToken usernameToken,
			RequestData data) throws WSSecurityException {
		// usernameToken.getName(), usernameToken.getPassword(), authenticate against
		// directory store or database. Do nothing if successful. Throw
		// throw new WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION); on failure.
	}

}

The final configuration on the server side is the web.xml file, which will initialize the Spring context, pass in our own Spring context as well as a couple from CXF (which are in its own jar files) to the ContextLoaderListener, and finally setup the CXF servlet which will handle all incoming requests for our service.

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
	xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
	version="3.0">
	<display-name>jax-ws-spring-test</display-name>

	<context-param>
		<!-- Spring contexts -->
		<param-name>contextConfigLocation</param-name>
		<param-value>
			classpath:META-INF/cxf/cxf.xml
      		        classpath:META-INF/cxf/cxf-servlet.xml
      		        /WEB-INF/cxfContext.xml
		</param-value>
	</context-param>

	<!-- Listener which bootstraps the Spring config files -->
	<listener>
		<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
	</listener>

	<!-- The CXF Servlet -->
	<servlet>
		<servlet-name>CXFServlet</servlet-name>
		<servlet-class>org.apache.cxf.transport.servlet.CXFServlet</servlet-class>
		<load-on-startup>1</load-on-startup>
	</servlet>
	<servlet-mapping>
		<servlet-name>CXFServlet</servlet-name>
		<url-pattern>/*</url-pattern>
	</servlet-mapping>

</web-app>

And thats it! Now if you were to fire up your server, package the project as a war and deploy it on the server, your web service should be up and running. You can verify this by navigation to http://localhost:8080//greetingservice?wsdl on your browser to view the WSDL that is automatically generated by CXF based on the JAX-WS annotations defined in your service class.

The Client:

To test the service, create a second Dynamic web project, and use the same build path as the previous project.

What we will need to create a working client to test the service:

1. The service interface which will be proxied by Spring.
2. A spring context configuration file to define the jaxws client proxy for the service.
3. A password callback handler which will supply the authentication token when invoking the service
4. A simple spring bean to test the proxy and invoke the greet operation.

The service interface can be generated from the WSDL either by CXF’s wsdl2java tool or Java 6′s wsimport utility. The source below was generated by wsimport when invoked as follows:

wsimport -d . -keep http://localhost:8080/jax-ws-spring-test/greetingservice?wsdl

package test;

import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebResult;
import javax.jws.WebService;
import javax.xml.ws.RequestWrapper;
import javax.xml.ws.ResponseWrapper;

/**
 * This class was generated by the JAX-WS RI.
 * JAX-WS RI 2.1.6 in JDK 6
 * Generated source version: 2.1
 *
 */
@WebService(name = "GreetingService", targetNamespace = "http://test/")
public interface GreetingService {

    /**
     *
     * @param user
     * @return
     *     returns java.lang.String
     */
    @WebMethod
    @WebResult(name = "greeting", targetNamespace = "")
    @RequestWrapper(localName = "greet", targetNamespace = "http://test/", className = "test.Greet")
    @ResponseWrapper(localName = "greetResponse", targetNamespace = "http://test/", className = "test.GreetResponse")
    public String greet(
        @WebParam(name = "user", targetNamespace = "")
        String user);

}

The client Spring context contains the client proxy definition and is shown next:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:jaxws="http://cxf.apache.org/jaxws"
	xmlns:soap="http://cxf.apache.org/bindings/soap" xmlns:cxf="http://cxf.apache.org/core"
	xsi:schemaLocation="
         http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
         http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
         http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd">

	<!-- Interceptors -->
	<bean id="logIn" class="org.apache.cxf.interceptor.LoggingInInterceptor" />
	<bean id="logOut" class="org.apache.cxf.interceptor.LoggingOutInterceptor" />
	<bean id="saajOut" class="org.apache.cxf.binding.soap.saaj.SAAJOutInterceptor" />
	<bean id="wss4jOut" class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor">
		<constructor-arg>
			<map>
				<entry key="action" value="UsernameToken Timestamp" />
				<entry key="user" value="ws-client" />
				<entry key="passwordType" value="PasswordText" />
				<entry key="passwordCallbackClass" value="test.PWCallbackHandler" />
			</map>
		</constructor-arg>
	</bean>

	<!-- The CXF Bus -->
	<cxf:bus>
		<cxf:features>
			<cxf:logging />
		</cxf:features>

		<cxf:inInterceptors>
			<ref bean="logIn" />
		</cxf:inInterceptors>
		<cxf:outInterceptors>
			<ref bean="logOut" />
		</cxf:outInterceptors>
		<cxf:inFaultInterceptors>
			<ref bean="logIn" />
		</cxf:inFaultInterceptors>
		<cxf:outFaultInterceptors>
			<ref bean="logOut" />
		</cxf:outFaultInterceptors>
	</cxf:bus>

	<!-- Client Proxies -->
	<jaxws:client
		name="{http://www.springframework.org/schema/beans}GreetingService"
		address="http://localhost:8080/<your_project_name>/greetingservice?wsdl"
		serviceClass="test.GreetingService"
		wsdlLocation="http://localhost:8080/<your_project_name>/greetingservice?wsdl"
		serviceName="GreetingService" endpointName="GreetingServicePort">

		<jaxws:outInterceptors>
			<ref bean="saajOut" />
			<ref bean="wss4jOut" />
		</jaxws:outInterceptors>
	</jaxws:client>

</beans>

Make sure you replace with the name of your project in the snippet above. Worthy of note is how the InInterceptors on the Server side are mirrored by OutInterceptors on the client side.

The PWCallbackHandler is an implementation of a CallbackHandler, and is responsible for providing the password to be encoded in the soap request header. Note that by calling the setIdentifier method, a different username can also be set. This allows for specifying different credentials per request. In a real world client, these values would probably come from a Session variable or from a SessionContextHolder.

package test;

import java.io.IOException;

import javax.security.auth.callback.Callback;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.UnsupportedCallbackException;

import org.apache.ws.security.WSPasswordCallback;

public class PWCallbackHandler implements CallbackHandler {

	@Override
	public void handle(Callback[] callbacks) throws IOException,
			UnsupportedCallbackException {
		WSPasswordCallback c = (WSPasswordCallback) callbacks[0];
		// in a real world client these would probably come from SecurityContextHolder
		// or some session object
		c.setIdentifier("jd");
		c.setPassword("secret");
	}

}

The Web.xml will contain the same content as the one from the server project.

Finally, we create a spring bean which will have the proxy injected, and will then call the greet method on the service:

package test;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.scheduling.annotation.Scheduled;
import org.springframework.stereotype.Service;

@Service
@Qualifier("greetingServiceClient")
public class GreetingServiceClient {

	@Autowired
	private GreetingService gs;

	@Scheduled(cron="0 m h * * ?")
	public void testService() {
		try {
			System.out.println(gs.greet("Jeshurun"));;
		} catch (Exception e) {
			e.printStackTrace();
		}
	}

}

Adjust the cron task by replacing the h with the hour of your current time, and m with two minutes plus your current time’s minute.

Deploying the project on the server, and waiting for the cron to kick in should print “Hi there, Jeshurun!”. You can even deploy the client on a separate machine to make it even more awesome.

To sum things up, lets see how CXF stacks up against other popular stacks:

1. Easy Spring integration by using custom namespaces.
2. Modular, lets you pick and choose eactly the features you need.
3. Setting up security is relatively easy.
4. Uses standard JAX-WS annotations, so your services can be ported easily to a different stack if needed.
5. Way better documentation compared to Metro, although not on par with Spring (but definitely getting there).
6. Performance is comparable to Metro and is faster than Axis.
7. Can be integrated right into your project and doesn’t force you to deploy each service as a separate war.

Some of the cons for me, which are making me think twice about using it:

1. There seems to be no easy way of defining the jaxws:endpoint or jaxws:client as an abstract bean and create beans which inherit common properties. Because of this, properties such as interceptors have to be redefined for every endpoint or client definition, even when they are exactly the same. This could make your configuration xml lengthy and error-prone in larger projects.
2. Can’t be configured to automagically detect POJOs annotated with @WebService and publish them, like Spring’s SimpleJaxWsServiceExporter.

Supposedly the problem occurs when the equals and compareTo method in the type contained in the Collections aren’t consistent with each other, and the sizes of the collections compared aren’t equal. Look at the following link for an example
JDK Bug 6394757 : (coll) AbstractSet.removeAll is surprisingly dependent on relative collection sizes.

Anyways, the rule of thumb for me from now is if need be to implement a SortedSet Set that will have either removeAll or retainAll called on, use an HashSet instead, and later use Collections.sort

Set<MyType> mySet = new HashSet<MyType>();
// add some elements, do some operations
mySet.removeAll(anotherCollection);
List<MyType> myList = new ArrayList<MyType>(mySet);
Collections.sort(myList);

After much thought I have decided to sell my Xperia X10. I have only had the phone for a few months, but as I develop apps for Android, I need a phone with the latest Android version.

I’ve attached some pictures below, and as you can see from them, the phone is in excellent shape and has no scratches on the body. I’ve always used a screen guard so the screen has no scratches as well, and I also have a new spare screen guard which I will give with the phone.

The phone comes with a 16GB microSD memory card. I’ve never used the headphones that came with it. My asking price is $315 + shipping. Click on the images to view them in full resolution.

Check out the pictures below:

Other Specifications:
2G Network: GSM 850 / 900 / 1800 / 1900
3G HSDPA: 850 / 1900 / 2100 / 800 – X10a for Americas
Display: 480 x 854 pixels, 4.0 inches TFT capacitive touchscreen
Memory: 1 GB storage, 384 MB RAM
Card slot: microSD, up to 32GB, 16GB card included
Data: 3G, EDGE, GPRS, HSDPA, Wi-Fi, Bluetooth, USB 2.0
Camera: 8 MP, 3264×2448 pixels, autofocus, LED flash
Operating System: Android OS 2.1

Full Specifications

What is interesting is that I started receiving these emails soon after of my credit card was used fraudulently online to purchase merchandise from stores in France. Thankfully, my bank refunded the purchases and issued me a new card.

Below is an screenshot of a phishing email masquerading to be from TD Canada Bank:

While phishing emails like these can be very much like the real thing, a little diligence can go a long way to help spot these as fake right away. Here are a few pointers from the image above that might help spot a fake email:

1. The email has a generic greeting. In this case its “Dear TD Canada Trust Valued Customer”. If the email were legitimately from your bank, they would know who you are, and would address the email to your name.
2. The link in the email is fraudulent. Although the link text seems to indicate that it leads to the actual TD site, it doesn’t. How do you identify this? Its simple. Just hover your mouse over the link and you would notice that it actually points to a completely different domain. And the link is not secure either (uses http:// instead of https://). The actual link is usually visible on your browser or email client’s status bar. Keep in mind though that the website this link leads to will be almost identical to the real thing.
   
3. There is almost always a sense of urgency in the email.
4. The emails are usually riddled with typos / grammatical errors.

Here is a similar email for RBC. Unfortunately I deleted mine so this image is courtesy of Google.

And this is the scam website it links to:

A few pointers that might help keep you from getting scammed:

1. Buy a reputed anti-virus product (Kaspersky is my personal favourite) if you don’t have one already and keep it updated all the time, if you are running Windows.
2. Don’t ever open unsolicited email from senders you don’t know / trust. The holiday season is prime time for amazing deals / offers that will entice you to drop your guard. Remember, the old adage still holds, “if its too good to be true, it probably isn’t”.
3. Switch to Linux! Well, at least when you are logging into your bank’s website / making purchases with your credit card. Most, if not all of these phishing emails and almost all viruses out there are targeted towards Windows users. Switching to Linux saves you a lot of pain as these Windows executable viruses have no impact on a Linux machine. Plus you can get away with not using an anti-virus. And its free! If you need Windows for a proprietary program such as Microsoft Office, you can always run Windows in a virtual machine such as VMware player.
4. If you think your financial information might have been compromised, contact your bank immediately.

If you have already fallen for one of these scams, don’t feel embarrassed! An eCard that was spoofed as being sent from the Whitehouse conned several employees of the US government this holiday season and stole several gigabytes of sensitive government data. This only shows that sometimes, even the experts can fall for these scams, although it beats me why the US government hasn’t heard of a simple thing called SPF yet!

Stay safe online this new year!

I’m not sure why this happens (and I haven’t had time to dig into the source, perhaps I will file a bug report when time permits), but to get around this the following steps worked:

1. Make sure you have remove the install directory.
2. Login to the front end.
3. Click on the “members” link on the top right and then click on the site admin’s username.
4. Right beside the username you should see a link which says [ Administrate user ]. Click on the link.
5. Re-authenticate yourself.
6. Click on proceed to acp.
7. You should now be looking at the admin panel.

Did this work for you? Do let me know in the comments below!

There presently seem to be at least three ways of doing this, and following is the low down on the easiest way I’ve found so far. If you just need to view the email, please skip to end of this post.

1. First identify the name the file is quarantined as from the notification email that would have been sent to the admin account. For messages marked as viruses, including emails containing encrypted archives, the line in the email might look something like “The message has been quarantined as: virus-n89eFiOoPVpn”. For other blocked emails the name would begin with “blocked-” or “banned-”.

2. Once you have the name, locate this file on the server. To do this, sudo as zimbra on the server and navigate to “/opt/zimbra/data/amavisd/quarantine/”. You should find the file in this folder.

3. Once you have the file name, run the following command:

/opt/zimbra/bin/zmlmtpinject -s <sender_email> /opt/zimbra/data/amavisd/quarantine/<file_name> -r <recipient_email>

Replace:

sender_email with your email or the email you would like the email to be sent as.
recipient_email with the recipient's email address.
file_name with the name of the banned file you identified from step one.

4. Done! Following is a list of additional options that are available with zmlmtpinject that you might find handy:

usage: LmtpInject [options] [files]
 where [options] are one of:
 -a,--address            lmtp server (default localhost)
 -d,--directory          message file directory
 -D,--domain             default per-connection recipient domain
 (default example.zimbra.com)
 -N,--every              report progress after every N messages
 (default 100)
 -p,--port               lmtp server port (default 7025)
 -q,--quiet                   don't print per-message status
 -r,--recipient          envelope recipients (rcpt to).  This option
 accepts multiple arguments, so it can't be last if a list of input files
 is used.
 -S,--stopAfter          stop after sending this many messages after
 warm-up
 -s,--sender             envelope sender (mail from)
 -t,--threads            number of worker threads (default 1)
 -T,--trace                   trace server/client traffic
 -u,--username           username prefix (default "user")
 -w,--warmUpThreshold    warm-up server with first N messages, then
 start measuring (default no warm-up)
 -z,--repeat             repeatedly inject these messages NUM times
 and [files] contain rfc822 messages.  If directory is specified, then
 [files] are ignored.

Alternatively, if you just want to view the email, and if you have an email client such as Thunderbird installed on your local computer, you could download the banned-whatever file locally, add a .eml extension to its name and you should be able to open it with your email client.

Credits: Zimbra user forums users ewilen and rsharpe.

This post is for those who are having trouble getting the update, especially those who de-branded the phone to get global updates in the past. Most of this was done with a bug in the SEUS software which allowed a firmware from a different region to be flashed to the phone.

The problem now is that SE have fixed this since then, and re-branding your phone back to Rogers firmware has become somewhat tricky. Re-branding is necessary as presently the generic flash tool for North America isn’t available yet, and the only way you can get the Android 2.1 update, while still keeping your model as X10a is to get the update from Rogers. I spent half a day trying to figure this out, and I thought I might post my findings here, hoping someone else might find it useful.

As a word of caution, before you update your phone, please backup all your personal information such as contacts and messages. You can use one of several available apps in the market to achieve this.

Disclaimer: Do this at your own risk! While the process is straightforward, there is a risk that you may brick your phone. I hereby absolve myself from any responsibility should you end up bricking your phone by following these steps.

1. You will need the following software installed on your computer:
   1. Sony Ericsson Update Service – Download from here
   2. 32-bit version of the Java Runtime. It is important to install the 32 bit version even on 64 bit computers, as the flasher has some compatibility issues with the 64 bit version. Next it is necessary to set the “path” environment variable to point to the folder where you installed Java. You can find a video of how to do this and the links to the 32 bit JRE downloads here.
2. Next, you need to download these two files. One is the flasher tool for overwriting the de-branded firmware on the phone with the default one from Rogers, and the other one is the firmware itself.
   1. Click to download the Flash tool (credits to original uploader)
   2. Click to download the firmware (credits to original uploader)
3. Extract the file “XIOFUB” using a tool such as WinRAR. All files will be extracted to a folder named X10Flash_Unbrick
4. Extract the file ”a_WWE_R1FA014_DEK” into a different folder and subsequently extract the two files it contains, namely “android_1233-6929_R11A_R1FA014″ and “phone”.
5. In the folder “android_1233-6929_R11A_R1FA014″
   1. Rename: “system_S1-SW-LIVE-AC12-0001-S1-PARTITION-WITH-SPARE.sin” to “system.sin”
   2. Rename: “userdata_S1-SW-LIVE-AC12-0001-S1-PARTITION-WITH-SPARE.sin” to “userdata.sin”
6. Copy all files in “phone” and “android_1233-6929_R11A_R1FA014″ into the directory of the other file that was downloaded: “XIOFUBX10Flash_Unbrick”. Overwrite all files located in this directory when prompted.
7. Now you need to find your device ID. You can only do this if you have connected your phone to the computer and used SEUS atleast once. To find the device id, press start and type “regedit”. Click edit>find, and type in “Vid_0fce&Pid_adde”.
8. The search may take a couple of minutes until the first result. Keep hitting edit->find next or the F3 key until you find a registry entry key called “DeviceInstance”. Double click the name field and copy the last section of that, it should look something like “5&2888d0ff&0&1″. This is your device ID. Paste this in the file named DeviceID.txt in the X10Flash_Unbrick folder, deleting the existing value, if any.
   If the search fails to find anything, make sure “Match whole string” is un-ticked, and click “find next”, if that fails, try “USBVID_0FCE&PID_ADDE”
   **Note: It changes with every diffrent USB port you use.
9. Run X10flash.bat (DONT right click and “Run as Administrator”), Connect phone in flash-mode(with phone powered off, hold back key then plug cable in), once the notification light turns on you have 5 seconds to start the flash (press any key) or the phone will continue to boot. The process takes a minute or two to complete(similar to flashing it to 2.1 in the first place if you had used the generic X10i flash tool).
10. If you get an error such as “java.io.IOException: Unable to open channel, GetLastError=0 at com.sonyericsson.cs.usbflashnative.impl.USBFlashNativeImpl.openChannel” then repeat step 9 until you come to the “DeviceInstance” key again. Only this time, don’t copy its value. Instead hit edit->find next until you find a different key named “DeviceInstance” with a different value and paste that into the DeviceID.txt file. You may need to repeat this step until you find a Device ID that works.
11. Unplug cable and boot phone, it will take a while to boot the first time.
12. At this point, it is possible that your phone fails to boot and you get a Phone icon with a yellow triangle containing an exclamation mark. Don’t panic! Just power off the phone and start up SEUS (installed from step one).
13. Accept the license and click start. Choose the phone as X10 and click next. When it prompts to connect the phone, connect one end of the USB cable to your phone. Press the back button on the phone, and while keeping the button pressed, connect the other end of the cable to the computer. Continue holding the back button until the program prompts you to “release the back button”
14. At this point, a window should pop up, saying a new update is available for the phone, mentioning a list of all the new features, including HD video recording. Start the update process and let it do its thing. Depending on your Internet connection speed, the whole process may take over an hour. If you are using a laptop, make sure its plugged into a power source! Don’t attempt to disconnect the phone at any point or you may end up bricking it.
15. Once the update is done, reboot the phone, and your phone should now be running Android 2.1!

This method should work for phones flashed with the X10i 2.1 firmware and are having issues with 3G, and should change the baseband back to X10a. Did this method work for you? Did you run into problems? Please leave a comment and let us know.

Have fun with Android 2.1! All credits for the process / tool go to XDA forum members.