Hello everyone
I have a fortimail unit configured in transparent mode located opposite the mail server in the same DMZ subnet.
After configuring the unit to be able to handle both incoming and outgoing mail traffic, both via webmail and clients (outlook, gmail etc...) everything works.
I set the proxy for incoming mails on port 1 (the one collagated to the DMZ switch and successively to the fortigate) while on port 3 connected to the server both options are in pass trought.
Coming to the point, I have printers located in some external districts of my company that show up sometimes with 192168.X.0/24 addresses or public IP address.
I see from the logs that the incoming sessions pass the spam check safely thanks in part to the authentication profile for SMTP connections AUTH
When a session arrives from a printer (I can see this since "Xerox_Scan" appears in the subject column)
Of my internal lan 192.168.0.X
the last associated mail event log reports the entry: "dsn=2.0.0, stat=Sent (Ok: queued)"
while if the session arrives from a Public Ip or Subnet from another district that shows up with 192.168.X.0/24 (again with subjective Xerox_Scan)
That would be the printers invoking a scan to an address in my domain using a dedicated account: printers@example.com
the last associated mail event log shows the entry: "dsn=4.7.25, stat=Deferred: 450 4.7.25 Client host rejected: cannot find your hostname"
Now, searching the internet the problem should reside on the reverse DNS PTR record, but I know that's not the problem since before the fortimail unit was installed everything was working normally.
Plus when connections come from a mail client like outlook even with public ip address, the problem does not exist. always presenting the entry: "dsn=2.0.0, stat=Sent (Ok: queued)"
What could it depend on?
Hello ideait,
Thank you for posting on the Community Forum.
I found this link that can help you:
Can you please tell me if it solved your problem?
Kindest regards,
Created on 10-12-2022 03:28 AM Edited on 10-12-2022 03:29 AM
Hi thanks but I have already read this guide and configured the fortimail unit correctly, in fact all connections work.
As explained above the problem exists only for SMTP conections sent by the printers from the districts of my network.
(e.g. 192.168.X.0/24) while the connections coming from my network where the fortigate resides and where the VIP of my zimbra server is configured in DMZ, 192.168.0.X/24 are forwarded without problems.
The log of these sessions are identical except for the last mail event log on the fortimail unit:
- relay=[192.168.10.6] [192.168.10.6], dsn=2.0.0, stat=Sent (Ok: queued as BB6ACB2C0167) [192.168.0.73]
- relay=[192.168.10.6] [192.168.10.6], dsn=4.7.25, stat=Deferred: 450 4.7.25 Client host rejected: cannot find your hostname, [192.168.4.216]
This should be the roceived response from the Zimbra server, the strange thing is that without the fortimail unit the problem was not prensetava, analyzing the zimbra logs we see that the mails have in the HELO the unit name fortimail.example.it
In the zimbra admin panel I tried to add to the Authorized MTA networks other than the local one, but the server response to the fortimail unit is still the same.
From webmail everything passes, from client (outlook) everything passes, from internal network 192.168.0.X/24 everything passes, from network 192.168.X.0 and/or public Ip, only SMTP sessions get this response log.
As it is the situation should depend only on the ZIMBRA server, the fact is that before the instalation of Fortimail this problem was not there from the client side.
Hi Miguel,
this message, although I am not that good with FortiMail, indicates that your recipient mail server has trouble to resolve your sending mail server.
This could be some reverse record missing or an incorrectly set domain somewhere in the communication to that server. That only a subset of internal printers cause this, would make it seem that your printer might have a sender name/email configured that cannot be resolved, say forti.local.
The lookup might be part of the Sender Policy Framework, SPF to prevent spammers from identifying them as mail services that a recipient cannot resolve them for. For example, you can fake that you are sending from fortinet.com, but your IP address that your message originates from is not matching the DNS result for fortinet.com. "cannot find your hostname" could be a result of this check.
Best regards,
Markus
From the zimbra logs I see that the emails show up with HELO fortimail.example.com
But this also happens for mails arriving from 192.168.0.X/24
Which then in theory should receive the same type of message
On zimbra we added the record that links back to the IP address of the fortimail unit, on the fortimail unit SPF check is disabled in the session inbound policy
On zimbra we also added the various subnets in the trusted networks such as MTA
I fully understand that the problem lies in the server response and so the problem should lurk there, but the fact is that before the fortimail installation these mails coming from 192.168.X.0/24 networks passed through without any problems.
So I assume there is something within the fortimail unit that needs to be set up, but from the logs I see that all other types of connections (web mail, outlook client, gmail, etc...) are working normally
The fortimail unit is configured as follows for now:
System->Network
1) Fortemail unit with proxy only on incoming connections on port 1.
Domain & User
1) Domain configured with relay tipe Host specifying IP address of zimbra SMTP server on port 25 and SMTP fallback on the same server on port 465 (SMTPS enable)
Transparent mode option
1) "this server is on" port 3 (where the server physically connects)
2) "hide the transaparent box" enable
3) "Use this domain's SMTP server to deliver the mail" enable
In system->mail setting->proxies
1) "use client-specified SMTP server to send email" enable
Hi Miguel,
while if the session arrives from a Public Ip or Subnet from another district that shows up with 192.168.X.0/24 (again with subjective Xerox_Scan)
That would be the printers invoking a scan to an address in my domain using a dedicated account: printers@example.com
From this part it sounds like NATting of some sort. Do a packet capture and see if the messages srcip reflects that as well. For inbound traffic from public IPs you do not require NAT (typically PAT is needed).
I do not know the FortiMail well enough to spot an error in that config, but still focus on the traffic itself. DNS for the host name/domain name, PTR records is what you should make sure matches. SPF is my expectation, but if it is already enabled I'm not sure what mechanism triggers this.
Can you describe the layout from printer to FortiMail with the error message a bit more visual?
Best regards,
Markus
I attach here the logs (message column) of the two different attempts to send scans via printer
That is, from the printer a user presses scan and sends the aforementioned to a domain email address (usually his own) so that he gets an email with the scan on his inbox.
Before the fortimail unit was added, no such problem was encountered.
Cross Search Session (10 min) External (other district in other city) Printer
STARTTLS=server, relay=[192.168.8.9], version=TLSv1.2, verify=NO, cipher=AES256-SHA256, bits=256/256 |
AUTH=server, relay=[192.168.8.9], authid=printer@example.com, mech=LOGIN, bits=0 |
from=<printer@example.com>, size=16598, class=0, nrcpts=1, msgid=<abgWk.0000@22006f6b-4975-11ed-8000-9c934ef3a2ce>, proto=ESMTP, daemon=SMTP_MTA, relay=[192.168.8.9] |
File name: Xerox Scan_11102022165815.pdf, scanned by Antivirus Scanner(clean) |
STARTTLS=client, relay=example.com., version=TLSv1.3, verify=CAFAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256 |
STARTTLS=client, cert-subject=/C=US/ST=N/A/O=Zimbra Collaboration Server/OU=Zimbra Collaboration Server/CN=example.com, cert-issuer=/C=US/ST=N/A/L=N/A/O=Zimbra Collaboration Server/OU=Zimbra Collaboration Server/CN=example.com, verifymsg=unable to get local issuer certificate |
to=<test@example.com>, delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=136598, relay=[192.168.10.6] [192.168.10.6], dsn=4.7.25, stat=Deferred: 450 4.7.25 Client host rejected: cannot find your hostname, [192.168.8.9] |
Cross Search Session (10 min) Internal Printer
STARTTLS=server, relay=[192.168.0.73], version=TLSv1.2, verify=NO, cipher=AES256-SHA256, bits=256/256 |
AUTH=server, relay=[192.168.0.73], authid=printer@example.com mech=LOGIN, bits=0 |
from=<printer@example.com>, size=120534, class=0, nrcpts=1, msgid=<abh2e.0000@ad8092d2-4975-11ed-8000-9c934ef39d6f>, proto=ESMTP, daemon=SMTP_MTA, relay=[192.168.0.73] |
File name: Xerox Scan_11102022170209.pdf, scanned by Antivirus Scanner(clean) |
STARTTLS=client, relay=example.com., version=TLSv1.3, verify=CAFAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256 |
STARTTLS=client, cert-subject=/C=US/ST=N/A/O=Zimbra Collaboration Server/OU=Zimbra Collaboration Server/CN=example.com, cert-issuer=/C=US/ST=N/A/L=N/A/O=Zimbra Collaboration Server/OU=Zimbra Collaboration Server/CN=example.com, verifymsg=unable to get local issuer certificate |
to=<test@example.com>, delay=00:00:01, xdelay=00:00:00, mailer=esmtp, pri=240534, relay=[192.168.10.6] [192.168.10.6], dsn=2.0.0, stat=Sent (Ok: queued as 7ACCAB2C0DFB) |
p.s. I have replaced the email addresses and domain name for privacy of my client
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1737 | |
1107 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.