Google Apps mail can be a great help when your servers are overloaded with traffic and just die when you send your newsletter or e-mail notifications to all your users. Then you learn about Google Apps and how you can just outsource your e-mail – personal and mass-email – to google. And it’s free! Standard version at least. Wow.

However after your first mass-mailing goes out you might find that your “domain has been disabled“. Google it, internet is full of stories of desperate admins and small business owners who can’t access their mail. Unfortunatelly standard version of Google Apps comes with no tech support – just online help. Seems fair enough. It’s free so READ THE FINE PRINT before you mass-mail your subscribers, right?

Ok, so you switch to premium paid version (40 EUR per every mail account) and hope to get some support. Just after you pay your accout gets fixed and you can send and receive e-mail again! Magic! :) But after another mass-mailing your account gets trimmed down or sth and whenever you try to send something you get a message like this:

Expected response code(s) [250] but got response [421 4.7.0 Try again later, closing connection. (MAIL)

You submit a ticket to tech support and wait. After a while they reply and tell you to check connectivity between your outgoing mail server and smtp.gmail.com with traceroute (check!). They also tell you to manualy try to reproduce the problem:

Do you have any server logs which clearly show Google shutting down the connection to your mail server? Is this reproducible by doing a manual telnet test to Google servers from a command line prompt on your mail server? Please try sending a test email from using manual telnet and see if Google closes connection on you.

The thing is you are using SSL so telnet 25 doesn’t work. You google the task at hand at come up with this procedure:

1. Login to your outgoing mail server

2. Type openssl s_client -crlf -connect smtp.gmail.com:465

3. Type EHLO <your mail server domain>, and then press ENTER

4. Type AUTH LOGIN. The server responds with an encrypted prompt for your user name (like 334 VXNlcm5hbWU6)

5. Enter your user name encrypted in base 64 – use this converter to encrypt yourname@gmail.com (use a personal e-mail account that works, not your Google Apps mail account)

6. The server responds with an encrypted base 64 prompt for your password (like 334 UGFzc3dvcmQ6). use this converter to encrypt your password – yea, I know – they can read your e-mail now ;-) so use another converter for your password, geez

7. Type MAIL FROM:<sender@domain.com> (don’t forget <>), and then press ENTER. If the sender is not permitted to send mail, the SMTP server returns an error.

8. Type RCPT TO:<recipient@remotedomain.com> (don’t forget <>), and then press ENTER. If the recipient is not a valid recipient or the server does not accept mail for this domain, the SMTP server returns an error.

9. Type DATA.

10. If desired, type message text, press ENTER, type a period (.), and then press ENTER again.

11. If mail is working properly, you should see a response similar to the following indicating that mail is queued for delivery:

250 2.0.0 OK

Note that you’ll get an error message if you don’t authenticate before sending test e-mail:

530-5.5.1 Authentication Required. Learn more at
530 5.5.1 http://mail.google.com/support/bin/answer.py?answer=14257

Took me an hour before figuring out how to authenticate ;-) Many thanks to MS for helping me out to figure out this procedure. Who would have thought?

Anyway I sent the test e-mail so no problem there. But I still get this bugger when sending e-mail from that same account but not manualy:

Expected response code(s) [250] but got response [421 4.7.0 Try again later, closing connection. (MAIL)

Perhaps this will help solve this mistery: http://code.google.com/intl/pl/apis/apps/reporting/google_apps_reporting_api.html

Hope so…

Will keep you posted. Let me know if you have similar problems.

UPDATE: found a cool reporting library (just download into apache accessible dir, access http://yoursite/reportingdemo.php) – everything seems to be fine, but still no success with emails going out

SOLVED! It seems our application was causing Google to disable mail accounts for flooding its servers with broken e-mail addresses (retrying attempts to send e-mail to addresses such as my@mailcom or mymail.com). So typical. After implementing a script cleaning up the broken addresses once a day everything seems to be fine.

» Subscribe to new posts by e-mail