#haraka

lnb: are you adding banners or anything like that?

_smf_, am I misunderstanding you on https://github.com/baudehlo/Haraka/pull/906 ?

ultimatt1: no - I don't think so. It's fine if you intended it to be like that, but if you're ever going to put the results into a custom Web UI instead of via Kibana; putting all the results into the root object isn't going to work that well as the front-end then requires knowledge of each plugin to be able to display anything.

"if you're ever going to put the results into a custom Web UI" <--- yes, I certainly will

Then aren't you making it difficult on yourself?

I can't see how, as I won't be presenting the data willy nilly, but in some carefully constructed format

I haven't done it yet, so I'm obviously ignorant here

If you have a 'plugin_results' container object e.g. { plugin_results: { p0f: { pass: ... fail: .... skip ...}, dnsbl: { pass: .... fail: .... skip: ....} } ....

right...

You can then simply do a 'walk' of the keys and display it nicely in a web interface.

As the results all have a standard format.

why can't I already do that?

You can then add extra bits for some of the plugins if you need.

Becuase you've put the plugin results in the root.

I can easily detect objects with "result_store" data in them

So you can't 'just' walk the keys.

Yeah - but that's a bit crap though isn't it?

uhhh, if you say so...

You're going to have to decend into each key and then check if it's the correct type.

If you put it in a results object; you don't have to do that. You save yourself a bit of code and the actual returned JSON looks a bit tidier IMO.

Is there a way to change how fields are presented in Kibana?

I've no idea; I don't use Kibana

I rolled my own UI as Kibana's authentication was totally useless for anything that is exposed on the internet.

true that

but for admins

(unless you pay $$$ for the module that deals with permissions)

it's fantastic

Yeah - that was no good for what I was writing.

I needed that functionality without having to expose ES to the internet.

I need subsets of those features w/o ES exposure

but I'll have extra meta data in the results that will be used to filter user "scope"

and constrain what each user is able to see

As Kibana 3 required direct access to ES via TCP; and that was puke to do. No idea if that has changed.

Yeah - I've already dealt with that in my web app.

Dunno, I'm using Kibana 4, which is a node.js app

it does require access to ES though

Kibana will never be exposed to the internet in our use

I think the general use case of log.elasticsearch should be targeted at kibana users

Ok

and in that case, not having plugin data in an object is a win

but, we could certainly have an option that shoves PI results into a 'plugin' container

for use cases where that helps (such as: I'm building my own web app)

that's something I might add a few months down the road. I don't want/need it for my personal Haraka server, but I might just decide you're right when I get around to consuming that data in the $work web app

Ok - np; it's was just a comment as it's something I ran into that I thought might help. No biggie.

If you hadn't mentioned, it, I'd just have done a bunch of "typeof ..." checks. By mentioning this, I'll give it a 2nd thought in the future. :)

Mail From: and Mail To: do they take multiple inputs? Or just one input?

Mail From & Rcpt To, sorry.

MAIL FROM is singular

RCPT TO is multiple

more specifically, RCPT TO is 1+

ultimatt1: In the headers from "To" would they then show up as singular or plural?

different format

ultimatt1: To one person and CC the others?

that's RFC.5322, see http://tools.ietf.org/html/rfc5322

ultimatt1: What page?

DragonPunch: see section 3.4

and 3.6.3. Destination Address Fields

and 3.6.2. Originator Fields

3.4 is the field format though.

True, but the oddity of From: being a list deserves his attention

well, possibly being a list

Yeah; rare as hens teeth though.

what's the point of Carbon Copying (CC) if you can have multiple RCPT TO's?

Or an array of To:

"secondary recipients"

I guess that's good enough.

DragonPunch: you're confusing headers with the message envelope.

The SMTP MAIL FROM:<foo@bar.com> sets the envelope-from and RCPT TO:<bar@foo.com> adds envelope-to

The envelope data is what is used for routing.

Just like with snail mail

kibana doesn't support objects in arrays

However inside the message the Headers like To: From: Cc: Bcc: are totally informational and not used at all for routing etc. They are displayed only by the MUA.

The MAIL FROM: and To: addresses can be totally different.

Ah, okay.

It's a common misunderstanding with email

the might not even exist

*they

informational only when DMARC is not in the picture. :) Then, the From: header domain must be aligned with either SPF or a DKIM signature

It's just really easy to get confused. Especially when I step back and ask myself from a scientific perspective "Why?" is this happening. Like, "Why does the squirrel eat the acorn from the tree". Sometimes, it's just best not to ask "Why?".

only if you like "magic"

Hmmm, I always wanted to be a wizard like Gandalf. Hehehe.

hmm

client company tries to send me mail. they use google and its bouncing back '550 HELO protocol mismatch'

Technical details of permanent failure:

Google tried to deliver your message, but it was rejected by the server for the recipient domain outbounds7.obsmtp.com by outbounds7.obsmtp.com. [64.18.6.12].

it is rejecting itself?

anyone?

lnb: it would seem that your Google sender is proxying their outbound via Outblaze and that's doing some weird protocol stuff.

Set mismatch=false in helo.checks.ini under the [reject] section to allow it.

so its our haraka server bouncing it huh?

Indeed - that is one of the tests from the helo.checks plugin that I wrote.

Basically - they're sending a HELO or EHLO, then later sending the opposite.

Which shouldn't happen.

looking under reject there is mismatch=true now

# it out?

Really? ^^^ read what I said.

sorry set it

restart haraka?

No - you shouldn't need to. Haraka will notice it's changed and will reload it.

ok

maillog shows nothing

loglevel=debug

i hope it works, thanks _smf_

i will send the client email telling them to try again