Rule to forward emails is failing

I created a rule with an account where emails are moved into a subfolder of the inbox then forwarded to an external email address. The inbound emails get places into the subfolder as expected, and it appears that there is an attempt to forward the email on (I see them in the queue).

In the queue under STATUS I see ‘PROCESSING ERROR’ with an INFO button next to it. Clicking on the info button I can get more info from the rcptlist with the following

" Fail-info: Internal connect error
Status: PROCESSING ERROR
MBox: INBOX"

Why isn’t forwarding working as expected? I have a feeling that it will be something simple, but I’ve no idea where to begin.

Ideas??

Hello,

In case you are still without any ideas please increase log level for PROCESSING service to Protocol Communication and retest you scenario. This time you should have more details into the Axigen log file (usually saved in /var/opt/axigen/log directory under everything.txt or default.txt).

HTH,
Ioan

Thanks for the idea. I set the Queue Processing service to log to processing.txt and ran tail on it to follow when I retried one of the items in the mail queue. Here is the result:

2021-05-12 15:43:21 +0000 08 mail PROCESSING:00262726: Start filter smtp routing
2021-05-12 15:43:21 +0000 08 mail PROCESSING:00262726: Processing started
2021-05-12 15:43:21 +0000 08 mail PROCESSING:00262726: No certificate loaded; disabling STARTTLS
2021-05-12 15:43:21 +0000 04 mail PROCESSING:00262726: Client’s 0.0.0.0:0 country (UNKNOWN) is banned
2021-05-12 15:43:21 +0000 08 mail PROCESSING:00262726: Set recipient steve@xxxxxxx.tk state to PROCESSING ERROR
2021-05-12 15:43:21 +0000 08 mail PROCESSING:00262726: Finished filtering mail object 262726 with filter: smtp routing
2021-05-12 15:43:21 +0000 08 mail PROCESSING:00262726: Set recipient steve@xxxxxxx.tk state to PROCESSING ERROR
2021-05-12 15:43:21 +0000 08 mail PROCESSING:00262726: Set mail state to PROCESSING ERROR
2021-05-12 15:43:21 +0000 08 mail PROCESSING:00262726: Processing finished
2021-05-12 15:43:21 +0000 08 mail PROCESSING:00262726: Shepherd thread finished processing signal<

Could this be related to the country filtering I have enabled? I’m only allowing Canada and US…

Update:

I turned off ‘Security & Filtering’ > ‘Additional AntiSpam Methods’ > ‘Country Filtering’ and retried the item in the queue.
The item went without complaint. Here is the log:

2021-05-12 09:11:54 -0700 08 mail PROCESSING:00262726: Allowed ssl versions set to: tls11 tls12 tls13
2021-05-12 09:11:54 -0700 08 mail PROCESSING:00262726: SSL cipher suite set to: ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH
2021-05-12 09:11:54 -0700 08 mail PROCESSING:00262726: Relay mail using default host: < xxxxxxxxx.tk:25>
2021-05-12 09:11:54 -0700 08 mail PROCESSING:00262726: Relay mail: found IPv4 MX entry 54.241.xxx.xxx for domain xxxxxxxxx.tk with priority 1
2021-05-12 09:11:54 -0700 08 mail PROCESSING:00262726: Use 54.241.xxx.xxx to relay mail 262726 for domain xxxxxxxxx.tk
2021-05-12 09:12:00 -0700 08 mail PROCESSING:00262726: Shepherd thread received signal for cleanup
2021-05-12 09:12:00 -0700 08 mail PROCESSING:00262726: Start mail cleanup
2021-05-12 09:12:00 -0700 08 mail PROCESSING:00262726: Mail removed from queue
2021-05-12 09:12:00 -0700 08 mail PROCESSING:00262726: Set mail state to REMOVED
2021-05-12 09:12:00 -0700 08 mail PROCESSING:00262726: Shepherd thread finished cleanup signal

So I guess now the question is: How do I get the forwarding rule to play nice with Country Filtering? Is there a way to get the server to do a dns lookup prior to processing the forward?

Thanks in advance for any assistance / hints…

Aha - thx for your update.

If you check the first logs the detected IP is 0.0.0.0 which is detected as “unknown” country.

Could you add the following single IP address as a safe one: 0.0.0.0

Thx,
Ioan

Loan,
you are brilliant! I re-enabled Country Filtering (reading the countries I needed), added the 0.0.0.0 as a safe IP address, and voila! The queue emptied on retry.

So, that seems to have fixed the issue. Does adding the 0.0.0.0 as a whitelisted IP have any negative repercussions for security?

Cheers
Steve

Hello Steve,

No, it should not have any negative repercussions for security. Could you please share the version of your Axigen installation?

BR,
Ioan

Sure, I’m running the latest and greatest 10.3.3.15 (I updated from 10.3.3.12 yesterday). On a OCI Ubuntu 20.04.2 instance

Thanks again for your help!

Cheers
Steve

Hello Steve,

In this case all should be fine.

On the other hand, without adding 0.0.0.0 as a GeoIP safe address I’m wondering if you were able to send messages (even to local hosted accounts) via WebMail interface as this fake IP address is used inside PROCESSING service for such messages (and other ones that are not received via SMTP-Receiving service).

BR,
Ioan

Hi Loan,

receiving and sending seemed to be just fine prior. It was just the forwarding that was getting stuck in the queue with the processing error.

One odd thing tho: my emails end up in the junk folders of both @me.com and @gmail.com addresses… I have dkim, dmarc, spf all set up and both of my domains score 10/10 at https://www.mail-tester.com

Weird. I’m going to re-enable the 0.0.0.0 (I had turned it off to test) and try again…

Hello Steve,

Could you share the EML sources of the email received in the Junk folders on those servers so I could take a look?

Thx,
Ioan