Session Domain - Reject

[reghardt]

I need help with pin-pointing where/what is causing the disposition on mail we're trying to receive form a a sender. I have submitted a ticket to support (2nd time) and not getting any help from them. Not much available on this topic in the KB also. Attached I have a screenshot of the log.

[ESCHAN_FTNT]

Hi Reghardt

Do refer to http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD40529

Session domain means the recipient email domain unable to be resolved via configured DNS. You can quickly do a MX lookup on the recipient email domain using the DNS to verify.

Regards

Chan Eng Siang

[Carl_Windsor_FTNT]

Right mouse click on the log entry  and do a cross search.  These will identify the source of the block.    Look in the Mail Event logs as this is likely related to not being able to resolve the sender domain which is configured under Session Profile >  Unauthenticated Session Settings > Check Sender Domain.

[reghardt]

Right click on the log entry just give the same information in the first default view (the list after the search)

ColumnContent[id="ext-gen2949"]#4643[2017-07-06[11:20:00[id="ext-gen2963"]ClassifierSession Domain[id="ext-gen2946"]DispositionReject[id="ext-gen2955"]Fromvideofied@security3.co.za[v669JF5s028342-v669JF5u028342[scrub1.mailzone.co.za [41.138.92.75]["REMOVED"[0[unknown[mta[0:1:0[OK[0200028343LevelinformationTypestatistics

I could not tell where in the policy the reason is for the block, but you've mentioned it's under; Session Profile >  Unauthenticated Session Settings > Check Sender Domain. I can turn that off, but that will affect the global policy for all incoming mail, and I don't want to risk turning it off. So is this something the client will need to address his/her side? I believe this is a automated system message so convincing the other side will not be in my favor.  Is the the only other possible solution then to setup a separate policy with this option disabled for the specific domain, and place this policy above the default one? Thanks,

[Carl_Windsor_FTNT · Accepted solution]

The issue is caused by the fact that security3.co.za is a non-existent domain so FortiMail is correctly doing its job and you are right not to turn that check off.

You could bypass, but this is really something fundamental DNS issue that the client needs to sort.  At a guess, they probably have a config issue in this automated messaging system and there is a subdomain missing from the sending address e.g. secuirty3.domain.co.za. I would push it back to them to resolve.

[reghardt]

Thank you Carl - This was my thinking too. Rather let them practice better mail protocol than having others at risk by allowing potential threads in.

[emnoc]

NXDOMAIN means no such domain in  common sense, think about it in this shape

"why would you allow  mail in from a domain that does not exist ? ", you can never reply to the sender ;)

So yes I agree the FML is doing it's job correctly. Mail sent from "non domains" are highly suspected as spam or mis-configurations, etc......

The same for mail sent from mail.domain that have no MX

just my 2ct opinions.

Ken