Hi everybody and a happy new year!

We currently have a problem with our mail server, the situation is as follows:

- We are using an OpenEMM server running on CentOS 5.7 to send newsletters to our clients. The server uses sendmail for outgoing mail

- Sendmail is configured to relay e-mails by our company's mail server using SASL Auth. The company mail server is running postfix.

This setup is working so far, e-mails sent by our OpenEMM server are relayed and delivered to the final recepient - No problem here.

However, for non-existing recepients, postfix will not send any non-delivery notification back to sendmail - And that's our problem.

For testing, we sent e-mails from our OpenEMM server by commandline to an invalid e-mail address:
On our company mail server (Postfix) this will produce the following log:
This case works as it should. Bounce sends a non-delivery notification back to our EMM server which can be received and processed.

When sending by EMM however, the log is slightly different:
In this case, Postfix won't send any non-delivery notification, and we can't figure out why.

I'm also attaching the relevant parts of the Sendmail logs on the EMM server:

By commandline:
By OpenEMM (note there is no ctladdr in this case - maybe that's the problem?):
We've already spent days trying to figure out a solution, but the problem still exists. Maybe somebody can point us into the right direction?

Many thanks & best regards,
Andy

With the EMM send, are the messages staying on the queue? Typically issues for name related failures result in deferrals as they are often transient, but this kind of failure should result in a 4xx error code. Issue 'mailq' and take a look to see if the message is sat there.

Typically messages stuck on the queue - if you've not changed the defaults - will retry with decreasing frequency for about a week, when they will finally bounce if they fail.

Why this would happen with EMM, but not with a CLI submitted message I can't be sure, but I suspect it may be related to the submission method.

Hi Leslie,

thanks for your reply! Actually the messages are being sent out, both by CLI and EMM - This works fine.

Our only problem is, when sending by EMM, the Postfix server won't send any non-delivery report back to sendmail in case the mail is undeliverable (ex. to foo@bar.invalid). However if we send the same message by CLI, Postfix will send it.

So we're wondering if there is maybe some kind of parameter which EMM could pass to the local sendmail instance to explicitly tell the smart host not to send any non-delivery report. Or maybe it's related to no ctladdr being present when sending by EMM (see log snippet). We've done extensive research on this already, but were unable to find a solution.

Any other ideas?

Best regards,
Andy

Not entirely sure I follow here.

From your example log, your error is *not* related to the address (foo@bar.invalid) being invalid, but because the DNS name cannot be found: "Host or domain name not found. Name service error for name=bar.invalid type=A: Host not found" NOT because the recipient is invalid.

This specific error can be transient as it could be down to a simple DNS server failure to provide the host name. That DNS issue may work itself out quickly, so typical behaviour would be to retain the message on the queue and retry it frequently. That said, I would expect to see a 4xx status code during the SMTP session for this - but it semi looks like you've got some weird 544 response.

So your error message above is, strictly speaking, nothing to do with an invalid recipient and should not bounce as such. Hence my remark, try it again, check the Postfix queue - you'll probably see the message sat there in a retry state of limbo.

To cover 'Invalid Recipients' for completeness;
Invalid recipients (no such user) generate 5xx SMTP codes (often thought of as permanent failures). Typically Postfix talks to the remote sever, offers RCPT TO user@domain.tld during the SMTP transaction and will either get a 200 go ahead, or 550 no such user. No bounce is produced as the message has never been delivered to the remote system, it has rejected it during the SMTP phase with an error code, not a bounce. Your Postfix is left holding the baby and *should* then generate an NDR and send the message back to the RETURN PATH address. Remote servers should not produce bounces after taking messages, this would be considered to be 'backscattering'.

Some (badly set up) servers (Exchange used to do this by default) accept mail for anybody at the domain name (catch all). This may result in mail vanishing into a black hole, but it won't result in any kind of bounce.

If your Postfix instance is unable to deliver a message because it gets a permanent failure (5xx) it would normally tell the client connected to it at the point it is trying to send the message using SMTP status codes, not bounces. I'm not familiar with EMM but it appears to be acting as 'the client' here. When you send via the CLI using Sendmail (the client) it seems to be successfully reporting back to you via a bounce. I suspect that is because Sendmail is injecting the message into Postfix in a different way (not via SMTP, but using local pickup). Hence you get the different behaviour - however this is just a 'best guess'.

Breaking all that waffle down into short English I suspect Postfix is telling EMM 'hey dude, that's an error generating mail you have there, so I'm not taking it' and EMM is left holding it like a twonk not knowing what to do with it. I stress, however, I am *not* familiar with EMM.