This is a clip of Danny created by Emma and I. Danny is one of Emmas ponies horses.

I’ve still been talking to HTC regarding my faulty Touch Pro 2. I even managed to get the case escalated to someone who says they do this all the time. He has agreed that HTC should cover the postage costs as per the Warranty Statement in my previous post and that he’d get back to me with more details within 24 hours. Sadly, this timeframe expired yesterday.

He did however inform me that the repairs may take up to 4 weeks plus shipping. I objected to that as this would mean that the phone has been off under warranty repair for 8 weeks in its lifetime. Apparently this has been raised with HTC management - I’ll wait and see what that actually means!

Just recently I had to set up a sendmail server for an office with 7 local users and more roaming users. The current setup had all users checking email via POP3 to the ISP. This is an issue as email sent locally within the office passed over the ADSL connection twice. Sendmail however is quite difficult to work with when it can’t handle the entire domain. As not all users on the domain have an account on the office server, email would bounce back as user unknown - even though a POP3 account existed with the ISP.

I’ll write up a dummy scenario to make this clearer.

• local1 - Checks email on the local server via IMAP. Server downloads email via fetchmail and throws it in the users IMAP mailstore.
• local2 - Same configuration as local1.
• remote1 - This user doesn’t have an account on the local server but gets email via the ISPs POP3 mail account.

All users have the same domain name in their email address. For this example, we’ll use mydomain.com.au.

The issue starts with a couple of common problems.

a) If we put mydomain.com.au in /etc/mail/local-host-names, then email between local1 and local2 will be handled locally - which is great. The problem though is that mail between local1 and remote1 will bounce with a ‘user unknown’ error.

b) Having a smarthost defined to send email out via the ISPs mail server will also mean that mail between local1 and local2 will also go to the smarthost - essentially uploading it to be downloaded again. This adds delay and also slows things down.

To fix this, we can use the virtusertable to rewrite the addresses of the email addresses - but by default, sendmail does not run the virtusertable on any addresses of domains it does not own.

We can however modify our sendmail.mc with the following code to tell sendmail to run domains we specify through the virtusertable! The code is as follows:

1
2
3

FEATURE(`virtusertable', `hash -o /etc/mail/virtusertable.db')dnl
LOCAL_CONFIG
F{VirtHost}/etc/mail/virtual-domains

Now we can add the domains we want to run the virtusertable on in /etc/mail/virtual-domains: mydomain.com.au

The final step in this solution is to then specify what users we want to rewrite to be local users. This is in /etc/mail/virtusertable:

1
2

local1@mydomain.com.au     local1@localhost
local2@mydomain.com.au     local2@localhost

Now when we test these addresses using sendmail -bt from the server, we see the address translation happen:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

# sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> /parse local1@mydomain.com.au
Cracked address = $g
Parsing envelope recipient address
canonify           input: local1 @ mydomain . com . au
Canonify2          input: local1 < @ mydomain . com . au >
Canonify2        returns: local1 < @ mydomain . com . au . >
canonify         returns: local1 < @ mydomain . com . au . >
parse              input: local1 < @ mydomain . com . au . >
Parse0             input: local1 < @ mydomain . com . au . >
Parse0           returns: local1 < @ mydomain . com . au . >
ParseLocal         input: local1 < @ mydomain . com . au . >
ParseLocal       returns: local1 < @ mydomain . com . au . >
Parse1             input: local1 < @ mydomain . com . au . >
Recurse            input: local1 @ localhost
canonify           input: local1 @ localhost
Canonify2          input: local1 < @ localhost >
Canonify2        returns: local1 < @ intranet . mydomain . com . au . >
canonify         returns: local1 < @ intranet . mydomain . com . au . >
parse              input: local1 < @ intranet . mydomain . com . au . >
Parse0             input: local1 < @ intranet . mydomain . com . au . >
Parse0           returns: local1 < @ intranet . mydomain . com . au . >
ParseLocal         input: local1 < @ intranet . mydomain . com . au . >
ParseLocal       returns: local1 < @ intranet . mydomain . com . au . >
Parse1             input: local1 < @ intranet . mydomain . com . au . >
Parse1           returns: $# local $: local1
parse            returns: $# local $: local1
Recurse          returns: $# local $: local1
Parse1           returns: $# local $: local1
parse            returns: $# local $: local1
2                  input: local1
2                returns: local1
EnvToL             input: local1
EnvToL           returns: local1
final              input: local1
final            returns: local1
mailer local, user local1

Checking against any other email address should show the normal delivery method - either normal MX lookup and delivery, or via a defined smarthost.

As a lot of you know, I got myself a HTC Touch Pro 2 a few months ago - and boy - am I starting to regret it. I bought the phone in March - it was returned under warranty in April, and now has to go back under warranty again. Read on for the full details of how HTC support is more than useless in looking after its customers.

The full story: Optus (my carrier) have rolled out an extensive 900Mhz 3G network over most of the regional and non-metro areas - so it makes sense to have 900Mhz 3G support. Sadly, Telstra seem to be the only carrier that has the Touch Pro 2 in Australia - which means it only supports 850Mhz & 2100Mhz. For this reason, I purchased my Touch Pro 2 directly from Singapore - as they are the only location I could find (other than Europe) that has support for 900Mhz & 2100Mhz 3G services.

I purchased my phone on 12th of March 2010. The phone arrived on the 18th of March. Great so far! I unwrapped the box and fired it up and was VERY impressed. I spent hours exploring every new feature. After a few days, I had it set up in a way that was just right for me and was getting very used to using it quickly and efficiently. Then after 2 weeks, the USB port died.

It was certainly a hardware fault. The USB port was not detected via Windows, nor could the bootloader show it connecting via USB. With all my time dealing with HTC devices, I knew this meant a warranty return.

I started off contacting HTC Australia - which then handballed me off to the “Global Warranty Service” area of HTC - which means calling HTC in Singapore. Sure I thought, after reading the Warranty Card. This should be nice and easy. How wrong I was.

First, I’ll draw your attention to the HTC Warranty Card. Specifically this part:

In the event of Product failure, the Customer should take the following actions:

a) Refer to the user manual in order to identify and possibly correct the problem.

b) If the problem cannot be resolved by reference to the user manual the Customer should then contact the dealer where such Product was purchased or visit your local HTC website, or HTC service center or www.htc.com for further information.

c) Before the Customer contacts HTC service agent, please ensure the following information is at hand:
•- The model and serial number, IMEI number of the Product.
•- The Customer’s full address and contact information.
•- A copy of the Customers original invoice, receipt or bill of sale of the purchase of the Product.

HTC will provide the Customer with instructions regarding how and when the defective Product should be returned. HTC will pay costs in connection with both the return of the defective product to HTC and the repaired Product back to the Customer if the Defective Product is within the Warranty Period.

Awesome! HTC really stand by their product - or so it seems. In reality, as soon as you contact HTC regarding the warranty, you realise that not only do you have to pay for shipping directly to HTC, they will also hold your device to ransom until you pay the shipping costs back to you FROM HTC as well! Sadly, I didn’t find this out until AFTER HTC already had my device. After lots of arguing with HTC Singapore, they decided to be nice and pay the return shipping costs. To make matters worse, until HTC contacted me to say I had to pay the shipping costs, I couldn’t find out if my phone had even been received by HTC!

So after 3 weeks of having no idea where my phone is or even if HTC were going to send my phone back to me, a package arrived with my repaired phone. In the box was a report telling me that they had replaced the LCD module and main board. Essentially, all they left the same was the case. This would normally be good news - however it goes further than that. When I received the phone back, the keyboard didn’t fit in its spot properly and felt warped. To add to this, the LED behind one of the keys is always stuck on full brightness. Surely this shouldn’t have even passed the QA on the repair - let alone be shipping back to a customer in this shape! That being said, I figured I could live with this - as I really did not want to go through the support process with HTC again!

Now lets fast forward to October. Oh no. The USB port has died again. The exact same symptoms as before. This time however, there is a new twist. The battery drains VERY fast. A full charge that used to last 48+ hours now only lasts 12. This is not good.

I started talking to HTC Singapore again. After a while of talking to them on the phone, I realised that this wasn’t going to get anywhere. Anything beyond basic English is well beyond them. They cannot understand why I am annoyed at the whole process and they refuse to do anything but ‘ship it back to us, pay us and we’ll look at it’ - paraphrased from broken English of course. After almost 4 weeks of waiting for them to get back to be via either email or phone, I decided to contact HTC America.

The good news is that HTC America actually understand English! The bad news is that they seem to be just as unwilling to help. After expressing my deep concerns about the entire process, Alan (referred to later as HTC Guy) tells me that in all reality, after paying to ship my device to HTC, I might be waiting 2 months for the repair, then the time for shipping back to me. Oh, and I have to pay for shipping both ways.

So, after about an hour talking to HTC Guy, I finally asked for a copy of the Global Warranty Statement - as it sure as hell isn’t the one that is on their web site. After a long time on hold and lots of consulting with a supervisor, I get asked for my return number and they will get back to me with some details of what the actual Global Warranty Statement is - as nobody could seem to find it.

edit: After 24 hours, no reply from HTC at all. For some reason, I am not surprised.

At the moment, all I can see is that the lovely 12 month warranty will consist of 1 month in transit, 2 months at repair facilities, 3 months of being faulty, 6 months of normal usage (if I’m lucky!).

It even got to me so much that I wrote letters (yes, actual postal mail letters!) to both HTC Taiwan and HTC America. Surprise, surprise though - no response to them either as yet.

Its been a while since I’ve given an update on my Digital CoPilot project. Things are progressing VERY well - The new WAC charts from AirServices should now be accurate to within 85 metres - which is 1 pixel! Route planning is completed and the device is currently being flight tested. A few bugs have been found and have been ironed out, but all in all, everything is slowly coming together.