We are just getting started and are transitioning 15 domains from Postini. Under the User Creation Mode, we have "SMTP Discovery" checked. We are not given the option (its greyed out) to select "Deny Delivery" under "When a Recipient is invalid". If I change the mode to explicit, I can select any of the options. If I then go back to SMTP discovery, the "Deny delivery" option stays selected but doesn't actually work. All we want is for an undeliverable message go back to the sender if they try to email an invalid user. We also want to keep the SMTP discovery on. Has anyone seen this behavior or have any ideas how to fix it?
What you're experiencing is normal behavior. SMTP Discovery is a function that only allows for the system to try all emails to your server. In order to block invalid recipients, you will have to use Explicit mode. There is no option to do both SMTP Discovery and block invalid recipients, as SMTP Discovery requires the ability to receive mail for recipients not listed in the control console to attempt them to your server.
Thanks for the answer. I'm still confused though. If our exchange server is sending a message back saying that its an invalid user, why isn't that message in turn sent back to the sender? That is how we are used to it with Postini and find it to be very important to get that message back as a lot of people misspell names, etc...
Explicit mode doesn't work for us since we are not doing any AD or directory synchronization or uploading a user list. I played around with explicit mode and its an option that simply won't work for us.
The SaaS Service will relay back the error we received when attempting to deliver the message, so an NDR should be issued. If it is not, I recommend contacting the support team that works with your account to determine if it is a sending server issue, or another problem.
I'm curious as to what challenges you experienced with Explicit mode? Many issues can be resolved by ensuring the user is created by one method or another (Directory Integration, Bulk Creation, or, Individual Creation). We actually recommend creating your users through any method, and then setting the system to Explicit to avoid invalid email delivery.
I will contact them about not receiving the NDR.
As far as the challenges, we don't want every user setup. If we setup every user, the price would get too high very quickly. We only had 40 or so users with Postini. The people not setup would get some spam and viruses would get stopped, but they didn't have a lot of email back and forth to the extent we needed them setup. If we setup explicit mode, email will get rejected for anyone we don't have setup and that isn't a good solution. We aren't going to do any directory integration. We will just have the mailboxes setup upon discovery. Does that answer your question?
It certainly does. The McAfee service is not designed to have "some filtered, some not filtered" to achieve price controls. All email passing through is essentially using the service and is being filtered by the default policy. Each person receiving email on the domain should be covered under a license in order to affectively use the product. Otherwise, the users will get the same level of filtering without being licensed.
We are now in the process of letting the SMTP discovery setup all of our users. Thanks for the information on that.
Its getting more interesting though. Any email sent from a @gmail.com address to an invalid user never receives an NDR. I see:
Recipient Disposition: [250 Bounce (550 Requested action not taken: mailbox unavailable); Mode: normal; Queued: no; Frontend TLS: yes; SPF: n/a]
in the message audit but it never makes it back to the sender mailbox. By invalid I mean that the user does not exist on our exchange server. Any ideas why it never makes it back to the gmail sender?
Next I sent a test from @yahoo.com to the same recipient as above. I received an NDR back to my @yahoo.ccom address but I do NOT see it in the message audit. Any ideas on this one as well?
Lastly, regarding the same user - I am seeing messages in quarantine for that same user as well. How can that be? Shouldn't an NDR have been sent back to the sender? It was spam so I'm happy it got caught, but how did it get past the error of the user not even existing? Is the system going to try to send the user a quarantine summary since spam was caught in quarantine?
Any help/information on this would be greatly appreciated. We just cutover 10 domains from Postini so all of this is happening suddenly and I don't have any answers on this behavior.
Message was edited by: lewispaskin on 7/19/13 6:54:23 PM CDT
Message was edited by: lewispaskin on 7/19/13 6:56:28 PM CDT
I'll answer your questions in the order they appeared:
Our server does issue an NDR. I get one when sending from a yahoo address but not from a gmail address. I called into Mcafee and spoke with somone in Denver. He tried a test from his gmail account and never received a bounce message but did see the NDR message in the log. We did the same from a yahoo address and did receive a bounce. When we had postini, we would always receive a bounce message regardless of where it came from (yahoo, gmail, etc...). From there he wasn't able to explain why this was happening with gmail. Not sure where to go from here. Its not the end of the world but it certainly doesn't make any sense. I don't specifically know of anyone else using this service but I'd be curious if anyone reading this could send an email to yyyzzz@<yourdomain.com> from a gmail account and see if anything happens.
I understand # 3 now, thanks.
I'll explain the point about NDRs a bit better. When an NDR is generated, it is not a message sent from the recipient server. It is a reply returned to the sending server, which must then send a NDR to the sender.
gmail.com connects to mxlogic.net to deliver a message, we simultaneously connect to your server.
gmail.com begins sending data to mxlogic.net, which is captured, filtered, and if clean, forwarded to your server.
At the rcpt to: command, your server returns an error stating no such user/invalid user/ etc.
That error message is relayed back to gmail.com during the transaction.
Gmai.com's servers should then turn around and email the sender with a NDR to alert them of the failure.
Which is why an NDR, Non-Delivery Report, is named as such, not a Non-Reciept Report. The NDR is the sending server alerting the sender that it could not successfully deliver the message for whatever reason. If the sending server is misconfigured or is purposefully not sending NDRs, this is the decision of the administrator of the sending server. All any recipient server can do is issue the error.