Skip to main content
ideait
ideait
Explorer
October 8, 2022
Question

Fortimail Transparent - Deffered session SMTP dsn=4.7.25 rejected: cannot find your hostname

  • October 8, 2022
  • 2 replies
  • 5341 views

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?

2 replies

Jean-Philippe_P
Staff & Editor
Jean-Philippe_P
Staff & Editor
October 11, 2022

Hello ideait,

 

Thank you for posting on the Community Forum.

 

I found this link that can help you:

 

https://docs.fortinet.com/document/fortimail/7.2.0/administration-guide/111620/transparent-mode-deployment

 

Can you please tell me if it solved your problem?

 

Kindest regards,

Jean-Philippe - Fortinet Community Team
ideait
ideaitAuthor
Explorer
October 12, 2022

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.

Markus_M
Staff & Editor
Markus_M
Staff & Editor
October 12, 2022

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

    ideait
    ideaitAuthor
    Explorer
    October 13, 2022

    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

     

    Markus_M
    Staff & Editor
    Markus_M
    Staff & Editor
    October 14, 2022

    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

     

    Terms & ConditionsAccessibility statement