Apologies if this feels like a noob question—I’m just transitioning from PMTA to KumoMTA, and I’m still wrapping my head around the architecture, especially when it comes to receiving regular emails and just logging them, like we used to do effortlessly in PMTA.
This makes it look like KumoMTA thinks I’m trying to inject mail for relaying, rather than receiving a legit inbound message to my MX.
Questions I Still Have:
What’s the correct way in KumoMTA to simply accept and log regular incoming messages, without relaying them anywhere?
In PMTA, we saw all inbound SMTP in the logs by default. In KumoMTA, do we need an explicit policy, queue, or routing setup for that?
When Validity asks for FBL at domain.com, i see we have fbl.domain.com in kumo docs as an ARF Domain in the listener domains policy helper, should that means those subdomains should have an A record point to the kumo server as well ?
If I used GSuite or Office365 as MX instead of KumoMTA in receiving regular emails will that could be unprofessional ?
at its core, kumomta is a relay; it takes messages in one side and relays them out the other. You can configure maildir or custom lua delivery protocol handlers if you don’t want to relay out using SMTP. There’s a lot of information about routing, custom delivery handlers and setting the protocol to maildir in the docs
Having set your mx record to point to Kumo, with relay_to = true you should be able to receive emails and have them logged. You have relay_to = false for mail.domain.com so Kumo is rejecting the inbound emails as expected. Just set relay_to = true and either put the message in maildir, or use LMTP to deliver it somewhere (LMTP is pretty new I think, not sure how/if it works yet), or just get the message data using msg:get_data() and post it somewhere and do whatever you need to do with it there. I have relay_to = true for all domains that have their mx record pointing to us (both our internal domains for fbl, etc, and customer domains), then some custom logic in the message generated event handler to figure out if the message is outbound (we are supposed to deliver the message to another server) or inbound (another server is trying to deliver a message to a mailbox with mx pointing to Kumo). IIRC, if it’s inbound, I use a custom lua delivery protocol to send it to our backend which saves the data in our db. I’ll have to double check to make sure what I’m doing exactly, but I don’t have access to my laptop until tomorrow afternoon.
they are not rejecting it but it try to push it to outbound, where exactly and how you identify an inbounce emails from a provider or an inject because they have a similar concept, since there’s an auth required in both via api and smtp.
Also if i can identify the different, maybe we can http post request to another webhook, or maildir.
and another question in docs, since fbl and bounce are subdomains, let’s say you set sender for return path as that bounce subdomain ? what about fbl ?
I have a list of domains registered with our esp for sending emails (along with their dkim keys and other information in a SQLite database), if the message recipient domain is in that list, I assume it’s inbound and handle it differently.
well that’s a special case, since you know who gonna send a msg to you, but we are speaking, let’s say about free providers or maybe webmails, you can’t really know all the domains
I don’t know who’s gonna send the message, I just know that it’s fine to accept inbound emails to domains registered in our system from anywhere, and that it’s fine to accept authenticated outbound messages to anywhere from the domains registered in our system
So, with relay_to set to true, Kumo accepts the email, the message generated event handler gets called, I check the sender and recipient domains, if sender domain is registered with us and auth is fine, it’s all good and the message gets queued for delivery. If not, I check the recipient domain, if it’s registered with us, i don’t care who sent it and where it came from, I just queue it to be handled by the custom lua delivery protocol (which just POSTs the message to some endpoint). Otherwise I reject the message.