Can't send e-mail

[Marcusg]

I noticed it right after I upgraded our clients to 1.23. (1.22 was only installed for about a day) that we could not send e-mail anymore!!!

I have copies of 1.22 and 1.23 and both versions are broken and will not send e-mail.

We have a barracuda spam firewall acting as a relay and AUTH proxy, as of version 1.21 (we still have a client that works on this version) MAPI would send e-mail but now it won't. I've tested this with 1.22 and 1.23 and neither of them will send through the barracuda. However, when re-directed to the mail server through an alternate port e-mail will send again.

Is there a change in the smtp commands? Or an additional AUTH command set that our barracuda needs to properly relay e-mail? It's really important we get this working? What changed in 1.21 to 1.22 to make this happen?

Thanks.

[MailEnable]

There was a change where it will specify an additional argument when attempting to issue the SMTP DATA command. It may be that the smtp proxy is taking offense to this string.
If you enable logging (just use the normal logging level), the client will log the actual SMTP session (including client commands and server responses). Other than that, I am not aware of any change, nor have we been able to reproduce the issue - allbeit without an SMTP proxy. It would be great if you could zip and send the Iutlook All.log (beta@mailenable.com will be simplest). Thanks.

[Marcusg]

The logs have been sent. I'll make note to just include logs in the future. Thanks.

[MailEnable]

Thanks for the logs. The problem is as I suspected.

To explain: MailEnable adds an extension to the DATA command: DATA ME-SAVETOSENT=TRUE
The presumption at the time was that the client would only be talking directly to MailEnable.

In other cases (eg: SMTP Proxies) can take offence to the additional (extended) parameter.

As an interim measure, the client has been modified to detect the server's 5XX response and re-issue the command without the additional param.
The effect however is that the message will not be saved to the sent items on the server.

We are in the final phase of testing an update inclusive of this patch: It can be donwnloaded from here: http://www.mailenable.com/MESetup124.EXE

An additional change included in this patch is a fix for out of memory and occasional crash (due to a bug in the unicode generation of one-time entryids)

[Marcusg]

This brings a new issue. The option that I think would be best for us is to forward traffic from 587 to port 25 on the mail server for outgoing mail.

Is there a way to limit or open that additional port somehow on the mail server in a way that only allows authenticated sending. But does not accept connections asking the server to receive e-mail?

That is other than creating an exclusive ip list (one that blocks everything but our office and a handful of other ips)?