how you are handing asynchronous and synchronous bounce

get-help
1

how you are handing asynchronous and synchronous bounce?
Example: I want to give immediate bounce for email which are out of storage.
How can I achieve this.

2

Hey there @youthful-zorse, thanks for posting. Please read the “Troubleshooting” and “How to Ask for Help” buttons below. If you would like a 1:1 support session from the KumoMTA team, details are at the “Book a Support Session” button below.

3

Out of storage is not a bounce, it’s a transient error and if you’ve set up the webhooks (or Kafka/rabbitmq) for receiving the log hooks, you log event you’ll receive will have TransientFailure as its type for out of storage.

4

But in general, sync bounces will have Bounce as the event type, async bounces will have OOB as their event type, and other failures will have TransientFailure.

5

but as per the configuration in the pmta we are showing soft-bounce for the mail which are out of storage

6

For reference:

7

As, I haven’t configure listener_domains.lua in my kumomta, do I need that

8

TransientFailure is the same as soft bounce. It means that you should retry sending the message because it’s possible the error will go away in some time. Hard bounces in KumoMTA are Bounce and OOB, and are used for errors that will not go away like when the recipient inbox doesn’t exist. If you get a Bounce or OOB it means that you should not try sending to the same recipient again.

9

Yes, please read the links I sent above. If you don’t configure it, you won’t receive OOB events

10

So, I need to capture oob and arf both correct?

11

ARF is for feedback loops and not related to bounces.

12
13

So, If want to give immediate bounce to out of storage emails how can I can achieve those

14

I don’t want those email to be transient failure

15

That functionality is not currently available. As fhf said, out of storage is generally accepted as being a temporarily failure. Permanent failures tell the remote host to not try again, but when connecting to a remote server with a full disk, the expectation is to try again later because eventually that disk will drain and the MTA relays messages out.

16

I completely with your point, but can I use any regex to achive those result, as in I want to give it soft-bounce?

17

when I am trying to deliver it at first attempts

18

Probably the best thing to do, assuming this is for your OTP use case, is to set shorter base delivery and max_age for the queues that hold those messages.

However, if you really want to treat a full-mailbox as a permanent failure, smtp_client_rewrite_delivery_status - KumoMTA Docs allows you rewrite a delivery status into something different.

19

@free-spirited-yorksh he means as the receiver MTA. When his message generators inject a message but KumoMTA has a full disk.

20

ah, I see. Yeah, we don’t support this, because it is out of spec and highly unusual. If you had some way of knowing that the spool was full then you could use kumo.reject to 421 the connection in the smtp_server_mail_from event handler.
We don’t have a handy way for you to tell that the disk is full though.

We’d be happy to add a lua function that will return the disk usage information for a given mount point if you will sponsor the time it takes to build that.