eg: the --tls option if you’re using swaks
Anyway we can restrict other protocols because the idea is to ensure everyone is authenticated except obviously OOB and ARF
if you’re not using TLS then you can’t auth. If your policy requires auth then that implies that all non-TLS SMTP sessions will be prevented from relaying
Ahh tricky. Yea that makes sense. Thanks Wez.
Are the IPs in the pool round-robin if no weights were assigned?
the default weight is 1, so if you don’t specify any weights then that is equivalent to round robin, as every member has the same weight
The only other priority item I have left is configuring bounces/complaints to be sent to customer’s assigned webhooks/emails. Any guidance on that would be great, Wez.
And thanks for that Tom. I think the AUTH for SMTP is working. I just need to do AUTH in similar way to HTTP. I will tinker around with that and ping you.
You can use conditionals when you write the webhooks.
IE:
kumo.on('make.webhook', function(domain, tenant, campaign)
if tenant == "Customer-A" then
local wh_target = 'http://customera.com/collector/'
end
if tenant == "Customer-XYZ" then
local wh_target = 'http://wxy.com/webhook/'
end
See the recent topic at Discord as well.
Hey @faithful-ostrich With the example in the docs using password_database
-- Use this to lookup and confirm a user/password credential
kumo.on('smtp_server_auth_plain', function(authz, authc, password)
local password_database = {
['scott'] = 'tiger',
}
if password == '' then
return false
end
return password_database[authc] == password
end)
It works well because it gives users error in verbose like so
<~ 250-PIPELINING
<~ 250-ENHANCEDSTATUSCODES
<~ 250 AUTH PLAIN
~> AUTH PLAIN AHNjb3R0AHR0aWdlcg==
<~* 535 5.7.8 AUTH invalid
*** No authentication type succeeded
~> QUIT
<~ 221 So long, and thanks for all the fish!
=== Connection closed with remote host.
The script above doesn’t seem to be doing that and neither does it seem to work. Not sure what we are doing wrong.
Hey there <@!900516762410442773>, did you just paste a trace with AUTH PLAIN in it?
The AUTH PLAIN part of an SMTP trace reveals the auth credentials; they are only obscured by base64 encoding, not encrypted.
I’d recommend that you change the credentials shown in that trace!
I copied exactly what was provided.
Is there a better way to see this query play out and see what’s happening during this AUTH check?
You mean this one right?
It should behave the same
Can you share a trace of what you are seeing?
The conversation output above is not actually coming from that Auth, it is just the result of the Auth. Fine but important distinction.
Maybe run Kcli-smtp-trace and share the output?