Google Mail's SMTP server is requiring you to connect with TLS, but you have configured fetchmail to never use TLS.
Check your fetchmail command line and configuration file for sslproto and make sure it is set to TLS1.
On the command line:
--sslproto TLS1
In the conf file:
sslproto TLS1
See the fetchmail documentation for more on configuring SSL/TLS.
This is a very complicated question given that the mail providers of the world do not readily provide statistics on their mail servers.
Self Diagnosis
To determine the answer to your question based on your own server/domain peers, you could enable SSL logging:
postconf -e \
smtpd_tls_loglevel = "1" \
smtpd_tls_security_level = "may"
postconf
postfix reload
This assumes that you save your mail syslog messages for a while. If not, perhaps set up a syslog archiving strategy and write a shell script to summarize the TLS usage on your server. Perhaps there are already script to do this.
Once you are comfortable that all of your peers support TLS and at the cipher and protocol strength that you are willing to enforce, then you can make an informed decision. Every environment is different. There is no one answer that will meet your needs.
My own personal experience
For what it's worth, my own personal mail server enforces TLS. This has a funny side effect of negating most of the spam bots, as most of them do not support TLS. (Up until that change, I was relying on the S25R regexp methodology)
Update
It has been one year since I answered this and the only problems I have had receiving email with TLS forced on was from the front end web servers at Blizzard (parental controls) and Linode's management system. Everyone else I interact with appears to support TLS with strong ciphers just fine.
Corporate Environment
In a corporate environment, I would strongly encourage you to enable TLS logging and leave that running for quite a long time before enforcing TLS. You can always enforce TLS for specific domain names in the tls_policy file.
postconf -d smtp_tls_policy_maps
The postfix site has some great documentation on the usage of tls policy maps. You can at least ensure that specific domains that provide sensitive information are encrypted even if an ISP tries to strip out the TLS support in the initial server connection.
Best Answer
Yes, it is still a bad idea.
Three reasons:
While the RFC you cited (RFC 2487) is in fact obsoleted by the current standard RFC 3207, the current standard keeps the MUST NOT verbiage you quoted in your question.
SMTP Clients are not required to implement STARTTLS. It is totally acceptable not to do so. While STARTTLS is becoming more common, it is absolutely not universal.
As a result of reasons 1 and 2, if you require STARTTLS on all incoming connections you will lose mail.
However:
Your server - your rules. If you want to arbitrarily reject any mail for any reason, or even no reason - that is your right and privilege. (does not mean that it is necessarily a great idea however)
Side notes:
You wont prevent spam by requiring STARTTLS, even if you require mutual STARTTLS authentication. Spammers can get certificates too - or create self-signed ones. Rejecting self-signed client certs will also result in losing legitimate mail.
STARTTLS is point-to-point encryption. The connecting system can still read the contents of the email. If you want real privacy, you need something end-to-end, such as OpenPGP or S/MIME.
That said, STARTTLS does remove one possible avenue for interception or MITM and therefore it is still a good idea to use it when feasible, ie when the other side supports it too.