missleading message:queue documentation (not ran before)

[dazoot]

In the plugins page the message:queue is advertised as running BEFORE the message is stored to the queue. By checking the code i think it runs AFTER hence the queue.removeMessage call in case of error.

Am i wrong ? @andris9

[andris9]

It's actually in an in-between state. The email contents have been stored, but the required queue data info has not. After message:queue you would also get queue:route. You can detect when a message has been completely processed by using the log:entry hook with entry.action==='QUEUED' like here

[dazoot]

I still think the documentation is missleading.

We had a script to slow down users sending huge attachments, which proved not work as expected because the mail was already stored when the hook was reached :)

We were throttling AFTER the body (huge) was saved (the thing we were trying to avoid).

[andris9]

Well, I'm not sure what would be the best solution for you. Once the SMTP clients issues that DATA command you must process the incoming email stream in full. Until the client has not issued that command, there could still be some routing-specific commands coming (RCPT TO).

I guess, you should probably use 'message:store' for this use case. It's issued immediately after DATA.

From the plugin docs:

• 'message:store' with arguments envelope, body (stream) called when message is about to be stored to disk. You should not modify the body stream in any way, otherwise you break the body hash, this hook is provided in case you want to store a message somewhere else than the outbound queue
• 'message:queue' with arguments envelope, messageInfo called when message is processed and ready to be pushed to queue. You should not modify the body stream in any way, otherwise you break the body hash

[andris9]

• 'message:store' - issued after DATA, before message content
• 'message:queue' - issued after DATA and message content, before setting up final delivery routing

[andris9]

I guess if you want to reject and not store a message, you could create a plugin for 'message:store' that redirects email content to /dev/null and once the message has been processed, returns a 4xx error for the client. ZoneMTA would still "receive" the full message, but the message would not be stored anywhere.

[dazoot]

Our hack was to send SIZE in RCPT_TO and rewrite envelope.to in the plugin.

But this issue is for updating the docs to not make people think that the plugin is ran before the message is stored to the queue (mongo). This mention that the plugin is ran before storing to queue confused us a lot since the size limitation we did was not working.

Maybe we can mention the details in the docs, that the message body is actually stored to the queue to make it clear.