Oct 28, 2020 
Support Center » Knowledgebase » How to control relaying - receive 'We do not relay' error.
 How to control relaying - receive 'We do not relay' error.

This article applies to VisNetic Mail Server and IceWarp Mail Server.

When a message is received and it is to a remote address (to a domain that is not in the Accounts button or Management version 8-9) it must be authorized using one of four relay checks:

Delivery button (version 7.x)

Mail Service - Security - Anti Relaying tab (version 8.x) - General tab (version 9)

  1. Is an IP in Relay From or Trusted IP: (recommend only private IP's - default)
  2. POP3 before send (Default is on)
  3. SMTP Auth (Can be used any time by configuring email client)
  4. Relay only if originator's domain is local (Mail Service - Security - Protection tab or Advanced tab version 9 - NOT RECOMMENDED, THIS IS FOR CLOSED NETWORKS)

If the connecting IP is using any one of the above options they will be allowed to relay.

IMPORTANT: Please review this Article for info on how to find and use the logs before continuing. Also note that it's recommended that you use a text editor, such as Notepad, to open the logs, do NOT open large logs (more than 5M) in the VisNetic Admin console. And you may need to review several days of logs before finding the information you need.

Search your SMTP and POP3 logs for the IP address of the connecting server. If the IP is using POP3 or SMTP to authenticate you will need to identify the account they are using and determine if it's a trusted IP, if not, you should temporarily disable the account so relaying does not continue.

If the IP is not using POP3 or SMTP to authenticate then the IP must be in the Relay from: field or Trusted IP field to relay.

Here's some general guide lines.

  1. If your mail server logs report '550 5.7.1 user@remotedomin... we do not relay joe@sendingdomain'
  2. Example log entry [2510] 00:33:24 >>> 550 5.7.1 user@remotedomin... we do not relay joe@sendingdomain

    This indicates that an inbound connection was rejected by VisNetic MailServer because the IP was not authenticated.

  3. If your mail server logs report '550 5.7.1 user@remotedomin... we do not relay joe@yourdomain'
  4. Example log entry [2510] 00:33:24 Client session <<< 550 5.7.1 user@remotedomin... we do not relay joe@yourdomain

    This indicates that an outbound connection was rejected by the remote server and your mail server was not trusted. This is unusual and happens rarely, if it does happen it could be related to incorrect DNS lookups. Try disabling DNS cache in VisNetic MailServer.

  5. SMTP authentication is configured by the client sending the mail. The client only needs the username and password for one account to be trusted.
  6. Example log entry for successful SMTP authentication

    >>> 250-your-host-name Hello remote-client [], pleased to meet you.
    <<< AUTH LOGIN
    >>> 334 VXNlcm5hbWU6
    <<< dGVzdA==
    >>> 334 UGFzc3dvcmQ6
    <<< cGFzcw==
    >>> 235 2.0.0 Authentication successful

    This is only a partial log showing successful authentication. If you are expecting a client to authenticate you must see this type of entry in the log. The base64 encoded data can be decoded from the following site. Decoding the username and password is a good way to find out what account is used for relaying, by either a trusted user or spammer.

    Base64 decoding

    Example log with base64 data decoded

    >>> 250-your-host-name Hello remote-client [], pleased to meet you.
    <<< AUTH LOGIN
    >>> 334 Username:
    <<< test
    >>> 334 Password:
    <<< pass
    >>> 235 2.0.0 Authentication successful

    By default VisNetic MailServer allows all authentication types for SMTP. This is best practice so your mail server will support the widest range of connecting clients. For example, AUTH CRAM-MD5 PLAIN LOGIN DIGEST-MD5 are defaults. If you change the AUTH defaults (search help file for Protocol Policy) you may encounter problems where some clients (Outlook only supports AUTH LOGIN) will not issue the AUTH command for authentication. This will result in a 'We do not relay' error. Keep in mind that the logs MUST report some type of AUTH exchange to be considered trusted.

Article Details
Article ID: 356
Created On: Nov 02, 2004 08:54 AM

 This answer was helpful  This answer was not helpful

 Login [Lost Password] 
Remember Me:
 Article Options
Home | Register | Submit a Ticket | Knowledgebase | News | Downloads