Google recommend sending through SMTP servers for professional domains. In most cases, it is not necessary unless you do not want your email recipients pick up your primary Google Apps domain information when you use “send mail as” facility.
All you need is getting a SMTP server ready to work with Google. Setup in Gmail is quite easy.
董总问我，什么是 Google Wave？
这问题问得好，我一时不晓得怎么回答，我知道他问这个问题不是问 Google Wave 的定义。要泛泛了解 Google Wave，何必问我，去看看 Google Wave Help 或者上 YouTube 看几个入门的 video 就可以。
那么换句话问，在各种交流方式层出不穷的今天，Google Wave 有什么独到的地方？我们已经有了 email (of course I refer to Gmail), IM, SNS；Google 通讯产品也出了不少，gmail, gtalk, orkut, voice, buzz, 现在又出了 wave。很多产品，比如 facebook, twitter 据称很火爆的产品我都没来得及用。这也说明一个问题，大部分产品都有独到的地方，即便火爆，但它们无法象 email 一样不可或缺，从而改变世界。
就功能而言，Google Wave 高出 gmail 很多，比如即时、自主、互动，等等特性，在 Google Wave introduction 里都有提及，不用我多说。我自己在使用 gmail 时碰到的问题是：尽管gmail很智能，但无法按自定义的、更多的线索归类。我想 Google Wave 更灵活，能弥补 gmail 的不足。但现在使用 Google Wave 的缺陷是必须拉对方进入 wave 才能共同享受 wave。我想如果能把 gmail 作为 wave object，发起人能单方面 wave by email，即使对方不加入 wave，发起人也能 enjoy wave，这样 wave 就完美了。
要不然，在还没有人手一个 wave 的今天，wave 就无法取代 gmail。要是我们还得开一个 tab 用 Google Wave，另一个 tab 用 gmail，那么反过来也会影响 Google Wave 的普及。我期盼着一个能把 gmail 取而代之的 Google Wave。
微软被人诟病得比较多的地方，一是卖得贵，二是不开放。我觉得卖什么价是微软的事情，只要它觉得有市场，谋求利润最大化不该受到指责；但我深恶痛绝不开放的行为。
用户在选择一个产品前，不会了解这个产品的所有功能和限制。只有在使用产品的过程中，不停地发掘它的功能也了解到它的限制。如果发掘了一项功能是意料之外的，那就是惊喜，如果了解到一项限制是卖方强加的（不是因为成本高昂或技术不成熟），那就是不给用户自由——希望用“不开放”去限制用户不去选择竞争对手的产品？那是不可能的。我更甚之，如果哪个卖方敢这样干，我立马改投它竞争对手的环抱。
所以，我说 Google mail 比 Hotmail 好，主要是因为 Google 远比微软开放。
今天发现，有人博文说 Hotmail 支持 POP3 了。很久没用 Hotmail 了，我也不晓得它什么时候开始支持 POP3。我赶紧试了一下，果然，Google mail 里很轻松地把 Hotmail 帐号添加了进来，而且 Google mail 一见到是 Hotmail 帐号，直接把参数给设置好了。
看来微软也在进步，不过是不是太迟了点？我从不用 Hotmail 作邮箱 (only as IM)，不过还是很高兴看到它支持了开放协议。
我用一个 Google 邮箱 pop 另一个 Google 邮箱的1139封会话。Pop 结束后，接收方显示只有 1125封会话。当时我以为是某些会话没有 Pop 成功。经过一番核对，发现老邮箱里独立的某些会话，在新邮箱里被合并成一个会话。
于是我对 Google 合并会话的条件算法产生了兴趣，又经过一番搜索，发现 Google 对此算法讳莫如深。其实这算法有很大缺陷，Feature request 讨论组里对手工分拆和合并会话的呼声就很高。我也很想要这个功能。
I had a very bad day yesterday with Google Apps Mail. This service is good overall, but this time was exception.
I newly set up a Google Apps account and created several user accounts last Friday. I used my administrator account to login and did some settings. Yesterday when other users wanted to login Google Apps Mail, they encountered this error:
The page isn’t redirecting properly
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
* This problem can sometimes be caused by disabling or refusing to accept
cookies.
The symptom was – Google was jumping between www.google.com and mail.google.com in an endless loop. I tried various browsers on different machines and had the same problem. Only Google Apps Mail was affected, while Google Apps Calendar, Documents and Sites were all right. And only user accounts created last Friday but never login until Monday were affected, while my account and newly created test account on Monday were all right.
I tried all suggested solutions in vain –
I tried to report this problem to Google but found nowhere to report (just because it is a free standard account?) I suppose it was a synchronisation problem among Google millions servers, which could be solved by itself giving time. However I was not sure of the time scale, so the final solution came up at the cost of losing incoming emails during weekends –
I deleted user accounts and re-create them. (Here comes another episode – Google won’t allow a newly deleted account being created within 5 days. The workaround is creating another user account and aliasing the old one.)
There is not an alternative to Google Apps Mail, which is free, configurable, and powerful.
Currently the only way of swapping primary domain of Google Apps is – remove the alias domain and re-setup as new.
In order to keep receiving emails during swapping primary domain, I have to find another email service provider for the transmission period. I am not surprised I can not find any. Google is good, which is why I am using it, but its uniqueness is not a cheerful thing for business. I have never practised on a mail server just because google apps mail is taking care of everything.
It challenged me finding another email service provider, and finally I gave up. I used email forward service from my domain registrars and forwarded incoming emails to another google apps account.
Google offer 50 users apps as standard for free. When my business grow over this figure, I prefer my own mail server(s) rather than paying google. It is a shame to be pushed to pay someone.
我几天前注意到 gmail ui2 改变了一下风格，当时以为只是 look and feel 改变，今天无意中发现 settings 里多了 labs （也可能这个 labs tab 早就存在了，我没注意）。有几个功能比较实用，我就启用了它们。
最有用的要数 Canned reponses。之前 gmail 一直没有内置的邮件模板功能，虽然可以通过 firefox plugin 或者 google gadget 达到模板功能，但我总认为不够方便，也不够正宗，所以我一直忍受着没有模板的低效率。
Canned reponses 声称是为懒人设计的（大概是从手机预置短信得来的启发），我用来做预置邮件模板，真是绝佳的解决方案。
我能想到的也是大部分人能想到的——我想用gmail smtp server代替magento内置的sendmail，这么做的好处是用gmail sent mail log all emails sent out by magento。gmail smtp server是我所知的唯一一个能记录发送邮件的smtp服务器（感谢google）。
Magento默认使用MTA发送邮件，后台configuration可以设置使用smtp发送邮件，但仅限于未使用ssl的smtp服务器，看来只能修改程序才能让Magento用上gmail ssl smtp server了。
似乎有很多人有这个想法但无法成功完成程序的修改。我参照了Use any smtp to send email (even gmail)的代码，但发现它无法连接gmail smtp server (可能以前可以，但gmail smtp server改了设置?)。
经我修改，在magento 1.1.8版测试可行的代码方案是：
修改/app/code/core/Mage/Core/Model/Email/Template.php, 找到public function send($email, $name=null, array $variables = array())，删掉此函数中最后几句：
try {
$mail->send(); // Zend_Mail warning..
$this->_mail = null;
}
catch (Exception $e) {
return false;
}
return true;
替换为：
$config = array(
'ssl' => 'ssl',
'port' => 465,
'auth' => 'login',
'username' => 'your_email',
'password' => 'your_password');
$transport = new Zend_Mail_Transport_Smtp('smtp.gmail.com', $config);
try {
$mail->send($transport); //add $transport object as parameter
$this->_mail = null;
}
catch (Exception $e) {
return false;
}
return true;
除此之外无需任何其他修改。赶紧试一下吧。
原贴主要的误导之处是一个错误的$config：
$config = array(
'ssl' => 'tls',
'port' => 465,
'auth' => 'login',
'username' => 'your_email',
'password' => 'your_password');
其实，如果非要使用tls的话，相应的port应该是587。tls+587的搭配虽然能发邮件，但编码不对，我想应该在程序其他地方相应调整。这个我就没去研究了，ssl+465已能正常发送邮件，我的想法已经实现了。
Google help有提到：
For your convenience, the Google Team monitors abuse@yourdomain.com and postmaster@yourdomain.com to ensure that we can properly address all reports of spam, abuse, and technical issues. If you’d like a copy of messages sent to abuse@yourdomain.com and postmaster@yourdomain.com, create email lists for both addresses, and add yourself as a recipient.
Since abuse and postmaster are reserved aliases, you won’t be able to use them as usernames or nicknames.
可我在读到这段说明之前，就建了两个email lists: abuse@mydomain.com 和 postmaster@mydomain.com，我并未想着要把这两个特殊地址创建为单独的邮箱用户，因为我觉得这样做有悖Google App Mail Best Practices。看来我和google想到一起去了。
这里我只是想谈谈企业和个人在使用email中冲突，以及如何有效地应用Google App Mail来避免冲突。
员工一录用，很多企业都会给员工一人一个企业域名、个人名字前缀的邮箱。作为对外业务联系的邮箱，应该保持稳定，但员工跳槽是普遍现象，英国人更喜欢跳槽，造成企业邮箱地址更新频繁。试想以下两个情景：
情景一：企业开有 paypal 帐号以及多个银行帐号，由会计人员负责，每个帐号都会要求一个或一个以上联系人的电子邮件。会计人员换动，要一一更新这些帐号里的电子邮件地址吗？
情景二：企业对网上业务的依赖度很高，企业对网上业务进行了细分，并有多名专员各自负责某项业务。网上业务对应的活动会直接通知到专员的邮箱。专员离职或岗位调动都要在网上业务的后台程序进行调整专员的电子邮件地址吗？
我们很难找到一个现成的工具能在情景一和二快速、批量地修改电子邮件地址。
也有企业干脆用sales, accounts之类的position 描述作为邮箱前缀，对外进行业务沟通。我不喜欢这样，发自sales@company.com的邮件给客户的第一感觉是冷冰冰，缺少personal contact的感觉。
我们需要在稳定性和个性化之间取得一个平衡。My best practices are –