SMTP puzzle

Hi everybody,

I'm using postfix on my computer as mta. When I send a mail to my gmail adress through postfix it is delivered to gmail mailbox and then automatically moved in the "spam" folder. That's because my IP address is not considered trustful, or something like that. But at least it is delivered. Instead, when I try to send a mail by telnetting to smtp1.google.com:25 and typing smtp commands the server refuses to accept the RCPT TO: my.address@gmail.com (again because of my ip). I don't understand this behavior. I chose the server smtp1.google.com because it appers as output of

dig google.com mx.

I also tried the servers which appear as output of

dig gmail.com mx

but in this case they don't even accept the command MAIL FROM:, answering with a syntax error

555 5.5.2 Syntax error

but i'm sure that i typed the command correctly.

So the puzzle is: how can postfix deliver the msg? which server is it using?

thanks

12 Replies

Your postfix logs will tell you what server it spoke to. Look for the "relay=" value in /var/log/maillog on "status=sent" lines.

> Your postfix logs will tell you what server it spoke to. Look for the "relay=" value in /var/log/maillog on "status=sent" lines.

This confirms that the server is the same listed by

dig gmail.com mx.

Still I don't understand what postfix tells to the server in order to have the mail delivered. When I try by telnet it continues to give the syntax error 555 which should mean something like "I didn't understand an extension to a MAIL or RCPT command", but i'm using a plain MAIL FROM: command. :?

Did you send a valid "HELO" first? What is the exact syntax you used?

It's not accepting the mail when you telnet because smtp1.google.com is not a valid MX for gmail.com. You ran 'dig google.com mx' when you should have run 'dig gmail.com mx'. You also need to make sure that your MAIL and RCPT commands have <> around the email address. In your example you didn't show the angle brackets being used and GMail will refuse a message without them.

As for the problem of GMail considering mail from your server to be spam, this is a big problem mostly caused by pressure on Google to shut down the spammers in their own network. They now rely more on reputation. The more people that mark your mail as non-spam the better chances you will have of your mail being delivered.

@SelfishMan:

As for the problem of GMail considering mail from your server to be spam, this is a big problem mostly caused by pressure on Google to shut down the spammers in their own network. They now rely more on reputation. The more people that mark your mail as non-spam the better chances you will have of your mail being delivered.

You have that last part a bit backwards. Generally speaking, Gmail filters new mail once people have begun marking other similar message as Spam in the past. I rarely get false positives in my Spam folders on Gmail, and they certainly don't expect you to non-spam all your mail before it gets accepted. This includes mail sent from my Linode.

I recommend checking your Postfix IPs to make sure they don't appear in any DNS-BLs, and also making sure your reverse dns is properly set up. Adding additional features like DKIM might help as well. Try sending the message to check-auth@verifier.port25.com, and see what results it gives you for the SpamAssassin test too.

> You also need to make sure that your MAIL and RCPT commands have <> around the email address.
Great! Now the mail and rcpt commands are accepted. Anyway, after the DATA command the server replies with

550-5.7.1 [151.66.38.251] The IP you're using to send mail is not authorized

550-5.7.1 to send email directly to our servers. Please use the SMTP

550-5.7.1 relay at your service provider instead. Learn more at

550 5.7.1 http://mail.google.com/support/bin/answ … swer=10336">http://mail.google.com/support/bin/answer.py?answer=10336 j9si14697256mue.5

and the msg is not delivered. On the other hand, with a "sendmail" command from the shell everything works (I mean: the msg arrives in the "spam" folder). But obviously my ip address is the same. I think that the problem lies in the fact that Postfix is "fluent" in speaking SMTP, but i am not . I encounter the same problems trying to "talk" with HTTP servers, for example :mrgreen:

@CybrMatt:

@SelfishMan:

As for the problem of GMail considering mail from your server to be spam, this is a big problem mostly caused by pressure on Google to shut down the spammers in their own network. They now rely more on reputation. The more people that mark your mail as non-spam the better chances you will have of your mail being delivered.

You have that last part a bit backwards. Generally speaking, Gmail filters new mail once people have begun marking other similar message as Spam in the past. I rarely get false positives in my Spam folders on Gmail, and they certainly don't expect you to non-spam all your mail before it gets accepted. This includes mail sent from my Linode.

GMail is having some serious issues with blocking too much legitimate mail. There are even huge threads in Google groups about GMail blocking Google alerts and other mail originating from within Google. It seems to me that the only source GMail should trust is mail originating from within Google.com (not GMail.com).

If you use GMail frequently you have probably trained the spam filters well enough to be accurate for you.

@stefano:

550-5.7.1 [151.66.38.251] The IP you're using to send mail is not authorized

550-5.7.1 to send email directly to our servers. Please use the SMTP

550-5.7.1 relay at your service provider instead. Learn more at

550 5.7.1 http://mail.google.com/support/bin/answ … swer=10336">http://mail.google.com/support/bin/answer.py?answer=10336 j9si14697256mue.5

The link tells you exactly what is wrong. Have you updated your reverse DNS to point to the server hostname? For example, if the sending server is named 'mail.mydomain.com' then the reverse should point to 'mail.mydomain.com'. Even though it isn't required, you should set your HELO to 'mail.mydomain.com' as well.

–Blaine

151.66.38.251 has no PTR record, and is listed on several popular blacklists. You will probably find that many email servers will refuse to accept messages from that ip.

Perhaps you should get a linode? :)

@SelfishMan:

The link tells you exactly what is wrong. Have you updated your reverse DNS to point to the server hostname? For example, if the sending server is named 'mail.mydomain.com' then the reverse should point to 'mail.mydomain.com'. Even though it isn't required, you should set your HELO to 'mail.mydomain.com' as well.

I do not have a domain name, postfix is installed on my laptop an my ip address changes every time I connect from a different point. I accept that gmail server rejects my mail, but I don't understand why the mail is accepted when I use the command "sendmail" from the shell.

anyway, thank you all for your aswers

@stefano:

Still I don't understand what postfix tells to the server in order to have the mail delivered.

You can set the following in main.cf to enable verbose debugging for any connections to/from google.com:

debugpeerlist = google.com

With the default debugpeerlevel of 2, this will pretty much show you the entire SMTP transaction that is taking place when postfix connects.

you should consider using a relay host (your linode is not a bad place for this) and enabling sasl in the smtp client to authenticate with it. This way, no matter where your laptop is connecting from, you can relay your mail through your linode (and your linode's (hopefully) clean ip address), and it should be accepted by most sites.

I do this the easy way, just by establishing an SSH tunnel:

ssh -L 25:localhost:25 user@linode

Then I tell my mail client the SMTP server is at localhost. All done!

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct