When attempting to send an email using the SocketTools SMTP client component or library, the connection is successful, however the SendMessage method or SmtpSendMessage function fails with an error indicating there were no valid recipients specified.
This error is indicated with the error code 12296, returned by the LastError property in the .NET class or ActiveX control. If you are using the Library Edition API, or the error code 0x80043008 is returned by the SmtpGetLastError function.
The error corresponds to the SMTP status code 554, and often includes an enhanced status code with a message similar to this:
5.7.1 <user@domain.tld>: Recipient address rejected: Access denied.
If you have checked the recipient address and you know it is valid, these are some of the most likely reasons you are getting this error:
-
The local computer you are submitting the message from is not trusted. This can often be the case when the mail server is on a local or private corporate network, and you're attempting to deliver the message to another user on that network. By default, most mail servers will be configured to trust only specific systems (typically those within a local subnet).
If the local system is not trusted by the mail server, you may need to authenticate with the server. Many mail servers are configured with very limited trust, and will only trust connections that originate from the server itself, requiring client connections to be authenticated.
-
If you are connecting to the server on port 25 or port 465, the recipient should be local to that server. If you are not explicitly authenticating with the mail server, it will usually reject the message if the recipient is not local (e.g.: the user account is not hosted locally on that specific mail server).
Mail servers which accept any recipient email address and automatically forward non-local emails are called open relays, and today that is generally considered a configuration error. Open relays are often abused to send unsolicited emails, and all modern mail server configurations disable that behavior by default.
-
If you are connecting to the server on port 587 (often called the "submission" port), authentication is not optional. You must call the Authenticate method if you're using the .NET class or ActiveX control, or the SmtpAuthenticate function if you're using the library API. In virtually all cases today, the connection to the server must be secure, using TLS 1.2 (or later).
Most servers will not allow clients to even attempt authentication unless they are using a secure connection. There may be the rare exception to this rule, but most mail servers today which accept mail being submitted on this port are configured to reject all recipients from an unauthenticated client session.
-
If you are connecting to the server using a non-standard port number, such as 2525, you will usually need to follow the same guidelines as with using port 587. You will need to authenticate the client session and the connection must be secure.
These non-standard ports are often configured to allow clients to work around situations where an Internet Service Provider (ISP) has blocked the standard ports. This is usually done in an attempt to prevent, or at least inhibit, the abuse of their network by malware.
Make sure you are connecting using the correct port number, usually port 587. Always use a secure connection, and authenticate your client session with a valid user name and password (or OAuth 2.0 token). When those steps are followed, the server should accept the recipient and deliver your message.
SocketTools Version
This article refers to the components in SocketTools 10 and subsequent versions. SocketTools 9 and previous versions will negotiate secure connections using TLS 1.0 as a supported protocol and this may cause some modern mail servers to reject the connection attempt.
By default, the current version of SocketTools will only use TLS 1.2 (or later) when establishing a secure connection. If your application is connecting to a legacy mail server which only supports TLS 1.0, you can specify this using a compatibility option.
Support for OAuth 2.0 is only available with the current version of SocketTools. This authentication option is not available in previous versions.
See Also
Mail Server Authentication Errors
Invalid or Unsupported Authentication Protocol
Testing Secure Connections with OpenSSL
Unable to Establish Security Context