Mail gateway errors do not propagate

RT Users
1

Hi there,

On a pristine, default, configuration when the mail-gateway rejects a message it won’t propagate to the MTA, so the sender won’t get any errors; but the mail-gateway just dropped the message.

For example, on a pristine configuration where Everyone does not have Create Ticket rights, if you submit an e-mail to RT you will get:

[72652] [Mon Jan  1 11:45:30 2024] [error]: mail-gateway error: Permission Denied: xxxxxxx@gmail.com has no right to create tickets in queue General (/opt/rt5/share/html/REST/1.0/NoAuth/mail-gateway:89)

But at the same time, it will reply with HTTP status 200,

127.0.0.1 - - [01/Jan/2024:12:45:30 +0100] "POST /rt/REST/1.0/NoAuth/mail-gateway HTTP/1.1" 200 43 "-" "rt-mailgate/5.0.5 libwww-perl/6.68"

So the MTA thinks the delivery was successful:

2024-01-01 12:45:30 1rKGjZ-000JUw-2i => |/opt/rt5/bin/rt-mailgate --queue "General" --action correspond --url https://rt.XXxXxx.cloud/rt <hola@rt.Xxxxx.cloud> R=system_aliases T=address_pipe
2024-01-01 12:45:30 1rKGjZ-000JUw-2i Completed

With the result of the e-mail being lost.

Shouldn’t the REST endpoint be returning some error code (like 403?) and this become an error exit from rt-mailgate so that the MTA can reject the message with some meaningul error?

marc

PS: I’m new to RT (had a simple deployment years ago, now starting from scratch)

2

Hi, Marc.
I’m new at RT too. I presume that at mail’s point of view it’s a successful connection, but later, at the application level (RT) there is an issue that must to be handled in some other way.
To mitigate this kind of issues, in other systems I’ve configured a mail rule to copy the message to trash in the mail account so I can recover any mail from error at app level (mails at trash last for 1 month).
This advice can helps you until you can find any solution for this problem.
Ciao.

3

Yeah, but this does not fix the main issue: neither you (admin) or the requestor know that the email was dropped on the first place. The error is silent unless you keep an eye on RT logs looking out for that.

From an MTA/LDA point of view, the server should respond with some HTTP status code that the mailgate can turn into a meaningful exit code that signals the failed delivery