autosupport SMTP rejected by mx*.netapp.com (554)

[criecm]

Since May 1, 00:53 CET, netapp.com's MX are refusing our netapps autosupport mails (with 554 code). Could you correct this or explain us why ? Our mail relays are not blacklisted anywhere we know about (tested agains hundreds RBLs), are DKIM signed, SPF valid…

[criecm · Accepted solution]

I understood that HTTPS is recommended, but our networks don't permit this now.

We have a working smtp relay, and since years we rely on this for autosupport, and it seems supported (while not preferred now). If SMTP support is to be dropped, I missed the announce.

The problem here is that netapp's MX servers were rejecting autosupport mails without any explanations, I consider this as a service failure, not a config problem on our side.

Anyway, it seems to have been corrected yesterday 20:38 CET … Hope this won't repeat !

Once again, if SMTP support is to be dropped, please let your customer know *before* dropping 🙂

[andris]

I'm glad to hear that the problem between your SMTP gateway and our SMTP servers has corrected itself...

To be clear, SMTP transport for AutoSupport to NetApp is still supported. It's just not the recommended choice.

See this technical report: Data ONTAP AutoSupport and On Demand Configuration

HTTPS

HTTPS uses TCP port 443. This protocol is the default transport protocol. This protocol supports AutoSupport On Demand and uploads of large files.

When AutoSupport messages are sent using HTTPS, the X.509 certificate of the NetApp AutoSupport server is validated, and the message content is encrypted.

NetApp strongly recommends using HTTPS transport for AutoSupport delivery for the following reasons:

• HTTPS transport is significantly more secure and reliable than SMTP
• HTTPS is not restricted by SMTP e-mail size constraints
• HTTPS is easy to configure and manage
• HTTPS transport can be used along with SMTP delivery to internal customer personnel or systems HTTPS enables integrated AutoSupport On Demand capability to expedite case resolution

[andris]

Robinpeter's suggestion was excellent - you can completely avoid SMTP issues by switching to HTTPS and all of the benefits that come with that transport protocol.

If you still need to resolve the SMTP issue, please contact NetApp via the Feedback Form on the NetApp Support Site. (select Category: AutoSupport and Sub Category: Other).

Provide all of the necessary details about your SMTP relays, domain name, and ideally - detailed transaction logs.

[robinpeter]

I'll recommend you changing the autosupport transport protocol to https (which enebale autosupport ondemand)

here is some info :-

https://library.netapp.com/ecmdocs/ECMP1196798/html/GUID-6F959368-F40F-4621-AD2F-71511ECB3277.html

• If you enable AutoSupport to send messages to NetApp technical support, you can use any of the following transport protocols:
  Protocol and port Description

  HTTPS on port 443	This is the default protocol. You should use this whenever possible. The certificate from the remote server is validated against the root certificate, unless you disable validation. The delivery uses an HTTP PUT request. With PUT, if the request fails during transmission, the request restarts where it left off. If the server receiving the request does not support PUT, the delivery uses an HTTP POST request.
  HTTP on port 80	This protocol is preferred over SMTP. The delivery uses an HTTP PUT request. With PUT, if the request fails during transmission, the request restarts where it left off. If the server receiving the request does not support PUT, the delivery uses an HTTP POST request.
  SMTP on port 25	You should use this protocol only if the network connection does not allow HTTPS or HTTP, because SMTP can introduce limitations on message length and line length.

if you use the recommended protocol (HTTPS) to send messages to NetApp technical support and you also want to send messages to your internal support organization, your messages would be transported using both HTTPS and SMTP, respectively.