Gmail always rejected our server mail, why?

Steve Reid Replied

10/8/2014 at 5:08 AM

If you actually want some help you should provide us with as much detail as possible, including whatever step you have tried and smartermail version, etc.

Bruce Barnes Replied

10/8/2014 at 6:28 AM

What is your domain name? We can test with that.

It would also be helpful if you were to post the HEADER portion of the rejected e-mail from Gmail. It probably has a code which begins with a 4 or 5 and has some other numbers following it, along with some other information about the rejection.

To go back to your question, rejection can happen for many reasons, including:

no rDNS

bad reputation (being on a spam database)

no SMTP authentication

sending to a bad e-mail address

there are lots of reasons e-mail can be rejected.

Bruce Barnes

ChicagoNetTech Inc

brucecnt@comcast.net

Phonr: (773) 491-9019

Phone: (224) 444-0169

E-Mail and DNS Security Specialist

Network Security Specialist

Customer Service Portal: https://portal.chicagonettech.com

Website: https://www.ChicagoNetTech.com

Security Blog: http://networkbastion.blogspot.com/

Web and E-Mail Hosting, E-Mail Security and Consulting

z

zeus yee Replied

10/8/2014 at 5:31 PM

we're using smartmail professional 10.4.
we setup each person email at admin@advancednet.com.my account under setting>users.
so just type the name of the staff n password. thats all.
other setting i have no idea.
Please help.
these 2 days there are too many gmail have been rejected.

z

zeus yee Replied

10/8/2014 at 10:41 PM

mine is (advancednet.com.my) is it same to (advancednet.com)?

Steve Reid Replied

10/9/2014 at 5:25 AM

Your logs may hold clues as to why you are being rejected... Ensure they are set to detailed, reproduce the problem, then check your logs.

Bruce Barnes Replied

10/9/2014 at 5:36 AM

Because I missed the .MY portion of your original domain name in the post, I have deleted my previous response and testing results and am reposting the external test results here.

Telnetting to mail.advandednet.com.my on port 25 gets a valid response:

220 advancednet.com.my
ehlo
250-advancednet.com.my Hello [173.XXX.XXX.XXX]
250-SIZE 31457280
250-AUTH LOGIN CRAM-MD5
250 OK

a test e-mail, sent to admin@advancednet.com.my shows as successfully being sent from my SmarterMail server:

(note that the sending e-mail address and IP address have been redacted in the log sample below)

[2014.10.09] 07:21:09 [88474] Delivery started for REDACTED@REDACTED.com at 7:21:09 AM
[2014.10.09] 07:21:12 [88474] Skipping spam checks: No local recipients
[2014.10.09] 07:21:15 [88474] Sending remote mail for REDACTED@REDACTED.com
[2014.10.09] 07:21:15 [88474] Initiating connection to 103.1.150.175
[2014.10.09] 07:21:15 [88474] Connecting to 103.1.150.175:25 (Id: 1)
[2014.10.09] 07:21:15 [88474] Binding to local IP 173.000.000.000:0 (Id: 1)
[2014.10.09] 07:21:16 [88474] Connection to 103.1.150.175:25 from 173.000.000.000:1920 succeeded (Id: 1)
[2014.10.09] 07:21:16 [88474] RSP: 220 advancednet.com.my
[2014.10.09] 07:21:16 [88474] CMD: EHLO securemail.chicagonettech.com
[2014.10.09] 07:21:16 [88474] RSP: 250-advancednet.com.my Hello [173.000.000.000]
[2014.10.09] 07:21:16 [88474] RSP: 250-SIZE 31457280
[2014.10.09] 07:21:16 [88474] RSP: 250-AUTH LOGIN CRAM-MD5
[2014.10.09] 07:21:16 [88474] RSP: 250 OK
[2014.10.09] 07:21:16 [88474] CMD: MAIL FROM:<REDACTED@REDACTED.com> SIZE=4688
[2014.10.09] 07:21:16 [88474] RSP: 250 OK <REDACTED@REDACTED.com> Sender ok
[2014.10.09] 07:21:16 [88474] CMD: RCPT TO:<admin@advancednet.com.my>
[2014.10.09] 07:21:17 [88474] RSP: 250 OK <admin@advancednet.com.my> Recipient ok
[2014.10.09] 07:21:17 [88474] CMD: DATA
[2014.10.09] 07:21:17 [88474] RSP: 354 Start mail input; end with <CRLF>.<CRLF>
[2014.10.09] 07:21:18 [88474] RSP: 250 OK
[2014.10.09] 07:21:18 [88474] CMD: QUIT
[2014.10.09] 07:21:18 [88474] RSP: 221 Service closing transmission channel
[2014.10.09] 07:21:18 [88474] Delivery for REDACTED@REDACTED.com to admin@advancednet.com.my has completed (Delivered)
[2014.10.09] 07:21:18 [88474] Delivery finished for REDACTED@REDACTED.com at 7:21:18 AM	[id:45988474]

Your DNS tests clear, showing only one minor error, the lack of an ABUSE@ADVANCEDNET.COM.MY. The lack of an ABUSE@ address is not normally enough to have your e-mail refused, but, in cases of reported abuse, YAHOO! is now rejecting e-mail from MX servers which do not have ABUSE@ e-mail addresses.*2

FAIL: Acceptance of ABUSE@ address not found

Original test results can be found here: http://www.dnsstuff.com/tools#dnsReport|type=domain&&value=advancednet.com.my, requires free account.

Mailservers are required, by RFC2142 Section 2, to have a valid abuse address that is accepting mail.*1

The abuse@advandecnet.com.my can be an ALIAS which points to a working e-mail address. Anything sent to abuse@ must be responded to by the MX server operator. Failure to have an abuse@ address, or to respond to complaints sent to abuse@ addresses can now be cause for several major ISPs to blacklist all e-mail from a domain.

Further testing of your actual SERVER configuration also indicates no major issues, excepting the fact that you have no SPF record:

MX Server config testing GOOD: NO SPF RECORD found - SPF record should be added | Not listed in any spam databases

Some antispam blacklists are now testing for valid SPF records and assigning partial spam weights when no SPF record is found.

Original test results can be found here: http://www.dnsstuff.com/mstc?nocache=8414, requires free account.

A good tool for generating an SPF record can be found here: Unlock the Inbox SPF Wizard

Existing SPF records can be tested here: Unlock The Inbox SPF Tool

You can test your MX server's overall configuration, and see any outstanding issues or problems, by sending an e-mail to mailtest@unlocktheinbox.com.

This automated testing system at mailtest@unlocktheinbox.com will run a battery of tests and return a message to you showing any issues or problems you need to resolve. The result e-mail will also give you suggested settings and links to the configuration tools for those settings..

*1 RFCs are established by the International Engineering Task Force (IETF) to establish protocols and standards for the operation of all things Internet. The protocols established by the IETF, when adhered to, guarantee that the various services hosted on the Internet, when programed and configured according to standard practices, will function properly.

The communications protocols established by the IETF guarantee that communications between services like MX, IIS, FTP, and other services and servers will function because of the standards accepted by the governing committees.

From the IETF official documents page at: https://www.ietf.org/newcomers.html#officialdocs

"The IETF does not standardize transmission hardware (we leave that to organizations like the IEEE and the ITU) and does not standardize specialized application layer protocols. For example, we leave HTML and XML standards to the World-Wide Web Consortium. But the IETF does standardize all the protocol layers in between, from IP itself up to general applications like email and HTTP."

For more information about the IETF, and to find out how you, or anyone else, can become a member of the IETF, and help to deliberate and oversee those standards, see: https://www.ietf.org/newcomers.html

*2 See: Why Am I Having Problems Getting My E-Mail Delivered? for more information on the new requirements imposed on MX server operators by large and small carriers as part of their efforts to stem the flow of spam and abusive e-mail.