Tag Info

Hot answers tagged

20

No, Google doesn't currently offer this service. Even if they did, it's a not a very good idea to have all of your local authentication sources in the cloud. Let's say that you do move all of your authentication to some cloud service. Now, imagine that your ISP has an outage. Now no one can log in, even though your local network is fine. That's bad. Even if ...


19

I had to wrap my SPF record in quotation marks for it to work. "v=spf1 include:_spf.google.com ~all"


17

Hotmail fails to use proper DNS rules. Hotmail will always try to deliver to the domain's A-record first and will ignore MX-records. If the domain A-record accepts a connection (eg. it runs a mailserver) it will try to deliver the email, which in most cases will not be an issue if the webserver and mail server are the same box. However, if an domain uses a ...


16

Easiest way to do this is to avoid using exim and to use sSMTP which is a lightweight MTA. All you need to do is install it: sudo apt-get install ssmtp mailutils and configure it (edit /etc/ssmtp/ssmtp.conf) to use your Google Mail servers see: root=noreply@yourdomain.com mailhub=smtp.gmail.com:587 UseSTARTTLS=yes UseTLS=yes ...


11

The delay appears to be within google's network. However, this is technically not a problem. SMTP delivery is not and should never be viewed as an instant method of communication. It's a store and forward with multiple stops along the way which means multiple queues and multiple locations where delays might occur. SMTP is designed this way and delays can ...


10

I work for a school of similar size. My recommendation: Focus on the network infrastructure as the first priority. Get beyond consumer level switches and internet access by implementing say, a Cisco ASA 5505 firewall combined with a Squid web proxy to do edge and http filtering and VPN connectivity. An ASA 5505 is probably less than 500$ with a support ...


9

You can't use a CNAME as a root for your domain. To quote Wikipedia's article on RFC 1034 : An alias defined in a CNAME record must have no other resource records of other types (MX, A, etc.) The reason for this is because the CNAME tells clients that (in essence) you need to look here for your answer, but this applies for the entire domain. So not ...


8

What about something like MXLogic? (which was sold to mcafee) It's a SaaS spam filter, but most provide outage protection, where they are storing the email for the length of the outage. "McAfee intelligently synchronizes and delivers an accurate record of up to 60 rolling days of outage-period message activity"


8

This is absolutely impossible. Yes, there are means to synchronize between local directory services and Google's directory, but that doesn't mean that you can use Google's directory like AD, OD, or even a simple LDAP service. Now, if all you want is to enable users to be able to use their Google credentials to sign into your application, look into OpenID.


8

In zone files, all domain names without trailing dot interpreted as relative to the zone. @ is a shortcut for the zone domain and if label is omitted, the last label is used. That is probably why in your last MX example you got no MX records. ; CNAME Records mail 3600 IN CNAME ghs.google.com. calendar 3600 IN CNAME ghs.google.com. docs ...


8

There are a couple things you can do with Google Apps. You can setup a SAML server connected to your AD network and then setup Google to authentication your Google Apps access against the SAML server. We have used a php application called simpleSAMLphp because we already have servers setup to run PHP and we have developers with php skills. The drawback of ...


8

The problem here is how Exchange itself works (O365): However mails sent from inside office 365 addressed to users with accounts in 0ffice365 continued to appear in office 365 mailboxes, and are not routed to the mx mail server (google apps), and thus are not appearing in google apps mail mail boxes. This is to be expected. Exchange isn't going ...


7

Nevertheless, if there is something I can or should do about this - I'd like to know Unfortunately, there isn't. You are at the mercy of the providers receiving the email to know it's 'complete' spam and discard it without issuing a bounce (which is not very likely). If you haven't already setup SPF records, you should consider doing so. This will ...


7

Congratulations, you've just received your first backscatter spam. Unfortunately, the root cause of backscatter spam is badly configured mail servers which accept a message before determining that it's undeliverable and then attempt to return it to the "From:" address, which is obviously fake. If there aren't a lot of them, you can forward them to ...


7

You want to prevent this sort of thing in the future? Use a real MTA instead of Google Apps. As you've discovered, it is certainly possible to relay emails through a GApps account, but it's far from ideal, and frankly, it's not what that service was built to do. They give you zero visibility into logs of any sort, which you'd need in order to troubleshoot ...


7

In the manage domain settings | service settings | email change the first option "web address" to point to the URL you want (i.e. mail.mydomain.com) then create a CNAME record that points mail.mydomain.com to ghs.google.com.


7

Yes, it is quite possible to push out certificate trusts to users. This is done through Group Policy. You can find it under Users -> Windows Settings - > Security Settings -> Public Key Policies. From there you can manage which certificates and certificate-authorities are to be trusted. The same hive exists on the Computer side of the GPO as well. You'll ...


7

Sorry, but your 90% reliability of GApps is way off. If their reliability was that bad, there's no way they would have the market share they currently do. If you insist that their uptime is that bad, I'd start looking into your own infrastructure to see if something is wrong. I've been using GApps Standard (the free version) for several personal and ...


6

You should let Google handle the mail reception / sending if your cloud should not take care of it. The MX DNS type is specific to mail and conveniently indicates (with priorities) which server will actually handle mail reception for a given domain. Thus avoiding the need to specify a mail server / subdomain. But it may work also without the mail. prefix, ...


6

I've moved to Google Apps for my family email and for a really small site that didn't get a huge amount of email but needed to be provisioned fast. The fact that you don't have to manage an email server is a massive plus - I don't know about you but mail servers can get pretty messy - fast. In saying all that however, if you're not in the US, moving your ...


6

There is an article on Google Apps help about this. http://www.google.com/support/a/bin/answer.py?hl=en&answer=33786 All you need to do is add that TXT record and you're set. I don't know what you mean by "fight SPAM", as all this does is authenticate that the e-mail you are sending is not spoofed, so all it will do is help you get your e-mail in ...


6

SPF doesn't prevent spam from being sent to you, it only helps ensure that no one sends spam as you. Also, when bulk mailing, some mail services (hotmail, google, yahoo) pretty much require the sender has an SPF record or else the mail will likely end up in junk mail folders. Also look into setting up a DomainKey record, as this is Microsoft's way of ...


6

In an effort to avoid another Exchange upgrade and buying more hardware I switched my company to Google Apps Enterprise about 2 years ago. We were about 40 people at the time, now we're a bit smaller... We've never looked back. It has worked incredibly well for us. While you can continue to use Outlook (especially with the recently released plugin from ...


6

No there is nothing you can do with DNS. There is probably no way for Google apps mail to directly feed to a pipe. You could either setup an alias in google apps that forwards to an email address that is hosted on your ticket system server. You could also setup something like fetchmail to retrieve the email via pop/imap and then send the received messages ...


6

There's a couple of limitations to Google's Standard (free) Edition (I'm assuming that's what you're using) that you should be aware of: You can only send to 500 external recipients daily: http://www.google.com/support/a/bin/answer.py?hl=en&answer=166862 I can't verify this, but I've read (somewhere) that the number of invalid/undeliverable addresses ...


6

It's not possible to replace your Domain Controller with Google Apps.


6

From RFC 2821 "Simple Mail Transfer Protocol", section 5 "Address Resolution and Mail Handling": The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found instead, the resulting name is processed as if it were the initial name. In general, this is how CNAMEs work. They are often mis-used, mis-understood, ...


5

There are some redundancies built into the SMTP protocol, specifically the retry interval. I've seen this run as long as four days, so I would not be concerned about this at all. Google has multiple MX targets, so you will most-likely receive your mail, even in the event of a temporary outage. Its delivery may be delayed, but your mail won't be lost.


5

You should set up the MX records per Google's documentation. http://support.google.com/a/bin/answer.py?hl=en&answer=174125 1 ASPMX.L.GOOGLE.COM 5 ALT1.ASPMX.L.GOOGLE.COM 5 ALT2.ASPMX.L.GOOGLE.COM 10 ASPMX2.GOOGLEMAIL.COM 10 ASPMX3.GOOGLEMAIL.COM Note that the 1/5/10 priorities can be 10/15/30 or 1/2/3 or 1/100/1000 and it'll be fine - they just have ...


5

I strongly suspect that Google is not going to allow another user to spoof email from your Google Apps domain using their servers. Change ~all to -all after adding any other authorized outbound mail servers to the list. Ambiguous SPF records are almost pointless, and there is limited anecdotal evidence within the ServerFault community that ~all may harm ...



Only top voted, non community-wiki answers of a minimum length are eligible