You have to ask E-Mail administrator to investigate why E-Mail server rejects mails from NetApp. There is very little that can be done from NetApp side here. I vaguely remember that some versions had problems with Exchange, but again - you need to gather information from mail server first.
Actually they have an old netapp in FAS2020 wherein the config for autosupport is the same with the new netapp FAS2552. We can recieve notification from the old netapp thats why we are confuse why is that the new netapp cannot send an autosupport notification.
Assume you've checked the obvious, that your mail server has the filer whitelisted as an SMTP sender.
In our case, after a lot of faffing around, a reboot of the filer fixed it. The consensus seemed to be the email daemon within OnTap had died. One the few times when I've found NetApp support less than fantastic, no one I spoke to (and we a very premium support) was able to offer a definitive method to diagnose this was the issue at the time or suggest a remedy other than rebooting.
When you say an old 2020 and the 2250 has the same configuration, do you mean that the 2250 now has the same IPs as the previous 2020, or are both systems still up and running right now (each with different IPs)?
Systems are both up but with different IP's. The client decided to still up the old netapp so that he can play around with it and check some configuration.
But the users are connected with the new netapp. Do you think that's a problem having the 2 netapp with same configuration but different IP's. Because they are experiencing a heavy traffic in the network also.
No, what I was getting at was that just because you have another NetApp array up and running - and pointing to the same SMTP relay server - doesn't automatically mean that ASUPs will work.
First place to start is the SMTP relay server itself (whether it's Exchange, a load balancer of some kind, etc...) to ensure that the new IPs of the FAS2552 are allowed to even relay via SMTP to begin with.
Additionally, that's why I mentioned posting the output of the /etc/rc and /etc/hosts files (if you could). Yes, you can ping the SMTP server IP, but that could just mean that there's a route somewhere on the controller that can reach it. It doesn't necessarily mean that you're reaching it via the correct IP - does that make sense? In this scenario, it's important to ensure that if you add an IP to the SMTP relay, that you add the correct originating IP. Most often times, it'll be the IP that's on the same subnet as the default gateway (at least on a 7-Mode system).
You can also run a traceroute to the SMTP server IP to see if there are any unusual hops in the data path.
Have you tried changing the autosupport.transport to https and kicking off a WEEKLY_LOG to see if it at least goes to NetApp and registers via the My AutoSupport site?
I found a solution to a similar issue that recently came up in our environment. Our messaging team recently upgraded some mail relay servers. On many of our older filers the (autosupport.from) was set to only the host name (somefiler). After I changed the value to a valid email address (email@example.com) it once again worked fine.