CipherMail accepts unkown recipients - Exchange creates NDR

Gateway
1

Hi,

I am currently testing with CipherMail as a future gateway solution.
And I am not a linux guy. So I use the Hyper V appliance.

My Ciphermail gateway is setup up between the internet and my on premise Exchange.

The Exchange server is configured with the transport agent “Recipient Filter Agent”.
In Ciphermail I acitvated “Reject unverified recipient”.
As far as I understood from now on Ciphermail would ask my Exchange if this recipient is valid and process the mail if the recipient exists… But if it’s not an existing recipient it would reject the mail without generating an NDR.
But if I test this scenario by sending an email to a non existing address Ciphermail processes this email and send it to my Exchange.
Exchange checks the recipient and rejects the email with an NDR.
As far as I understood this is unwanted backscatter behaviour especially it the sender address is a faked one.
So now I am confused what’s going wrong. Should’nt reject CipherMail the wrong email in the first place? Or is there something configured wrong within Exchange?
Or do I have to configure something different which is’nt accessable via the web interface?

Thanks

Dirk

2

I know of two reasons (there might be more) why recipient validation does not work as expected:

  1. The IP address of the client that connects to the gateway is listed under My networks (see MTA — CipherMail Documentation).
  2. The Exchange server only checks the recipient after accepting the email and then sends an NDR.

1. Sender IP is on My networks list

The Postfix configuration provided by CipherMail, has the following smtpd_recipient_restrictions settings

smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination 
    ${djigzo_rbl_clients} 
    ${djigzo_reject_unverified_recipient? reject_unverified_recipient}

This means that if the connecting IP is in the My networks lists, the email is accepted.

If you want Postfix to check the recipient if the sender IP address is on My networks, move the verification step before permit_mynetworks

smtpd_recipient_restrictions = ${djigzo_reject_unverified_recipient? reject_unverified_recipient}
    permit_mynetworks reject_unauth_destination 
    ${djigzo_rbl_clients}

If you have also configured smtpd_relay_restrictions, also make sure that recipient verification is done before other checks.

Disclaimer: I have only briefly tested the above settings

2. Exchange does not validate the recipient before accepting

Recipient validation only works if the mail server you connect to validates recipients before accepting.

To test whether the mail server validates recipients before accepting you can use telnet to simulate an SMTP client

$ telnet some-smtp-server 25

EHLO test
MAIL FROM:<>
RCPT TO: <bugus-recipient@example.com>

The mail server should reject the recipient.

3

For a brief moment I thought maybe the latest ip address could be my gateway which is part of the “my network” configuration.
But that’s obviously not the case. Of course the delivering ip’s are external ip’s which are not defined via “my network”.
So this leads us to your second guess and I think there is the culprit.
After research to this topic I found some claims which exactly are describing the following:
It seems to be a wanted behaviour by Microsoft to check the recipient only after DATA reception even if the filter agent is configured correctly. This is a process which occurs only at the Exchange frontend listening at port 25. The Exchange backend at port 2525 is able to check the recipient after “rcpt to” state and rejects the mail earlier.But at this point the emails is already accepted in the first place.
And now Exchange is responsable to generate the NDR.
I don’t get it why Microsoft differs at this point.
Unfortunately I can’t portforward from CipherMail directly to the Exchange backend at port 2525 because my antispam / antivirus filter listens at port 25.
This means Exchange is not able to reject the unwanted email and pass the responsibility for generating the NDR to the sending server?

That’s weird.

Just for the records:
Found sources to this are for example
E2013 Recipient Filter (german)
Enabling Recipient Verification in Microsoft Exchange (english)

4

Postfix allows you to use different relayhost settings for the verification probe

http://www.postfix.org/ADDRESS_VERIFICATION_README.html#probe_routing

You might try the following postfix setting:

address_verify_relayhost=[exchange.example.com]:2525

Note: I did not test this

5

Hi Martijn,

thank you for your patience and time.

As I mentioned I’m unfortunately not familiar with Linux at all, but I’ve done some research and tried your suggestions.

I’ve added the relay host line to main.cf file.
Immediately after this postfix runs in a compatibilty mode which I guess means all added lines are ignored for stability reasons.
So I added the suggested line " compatibility_level = 2" and the note at the log files about compatibilty mode are gone.
But if this is correct so far it seems the relay host setting does not work.

I always get a rcpt to “ok” even though the address is rubbish.

Anyway, I’m going to put this on hold for now.
Maybe there will be a clue or a solution in the future.

Merry Christmas to you all.