Tag Info

New answers tagged

0

It may take more than one step to fix this issue Take the step mentioned earlier. Log into your google email account and then go to this link: https://www.google.com/settings/security/lesssecureapps and set "Access for less secure apps" to ON. Test to see if your issue is resolved. If it isn't resolved, as it wasn't for me, continue to Step #2. Go to ...


1

You must not authenticate for each email you should send. At the beginning of the process: Session session = loadSession(); Transport transport = session.getTransport("smtp"); transport.connect("example@gmail.com", "password"); After, use the transport object for send each mail without start session: transport.sendMessage(message, ...


2

It seems to be a bug that Gmail does not respect the ESMTPA in the Received header to show the MUA is a trusted host. Some possible workarounds come to mind: use split MX, that is, one Exim instance to receive and forward from authenticated clients, and a second to receive into mailboxes. That simulates the ISP-to-ISP mail that Gmail may be expecting, ...


5

[...] we import that mail in Gmail like any other emails from our boxes [...] That's wrong, as the mail headers tell as something different: Received: from server.webvizarts.com (server.webvizarts.com . [188.40.153.39]) by mx.google.com with ESMTPS id ge6si41332059wjd.24.2015.02.19.06.26.03 for <example@gmail.com> ...


7

Disclaimer: This answer was speculation one until GMail person confirmed it. Looks like it's GMail mishandle your fetched email here. Some peoples also report similar case with yours in here, here or here The problem is: GMail also deploying SPF measure when scanning email after fetching it via POP3. Normally SPF-checking take place in SMTP transaction ...


2

The problem was: The server certificate was signed with a SHA-512 hash. Debian 7 still comes with gnutls 2.x, but gnutls 3.x is required to savely use SHA-512 signed certificates. I was installing this certificate on Dec 23, 2014. Google seems to have altered their policies in cipher negotiation to be more strict on fall back cipher suits and/or signature ...


1

You know, I finally gave up. I moved everything to another VPS and now the emails are coming through as not spam.. So, tabula rasa is the best solution IMO.


4

Use the right tool for the job. Gmail is not that. Gmail is meant for normal, human users and the normal email usage pattern that goes with that. Use a purpose-built email service like Amazon SES, Mandrill, etc., and you'll have much better results without having to resort to hackery.


1

The only reasonable thing I can suggest is to make your forwarding use SRS so that any SPF checks use the originating sender. But ultimately it comes down to the "their servers, their rules" problem. If you don't want to pay Google for their services then they can do what they want and leave you with nobody to talk to. SRS info: http://www.openspf.org/SRS


6

I see two solutions here. (i did configuration like this many years ago) google use many ip's as MX. You can define in transport map, that first mail is routed via gmail-smtp-in.l.google.com., and second via alt1.gmail-smtp-in.l.google.com. Then - using iptables and nat/POSTROUTING - nat connections to first google MX via first ip, and to second google MX ...



Top 50 recent answers are included