The question is: what's the semantics of this log field? In the
trace slice I'm looking at, it's just the server,client. Is it meant
to have the Received chain?
The meta-question is: how am I supposed to find documentation for stuff
like this? Searching on "smtp path" from bro-ids.org didn't bring up
obvious hits. It wasn't that hard to navigate my way to:
I forgot to answer this question too. Yes, it's the path derived from the received headers and it's in reverse order where the actual message originator would be found at the right side and the receiver would be at the left.
Yes, it's the path derived from the received headers and it's in reverse
order where the actual message originator would be found at the right side
and the receiver would be at the left.
But what about adding the client & server? Are those added separately?
It would appear so, though I'm not sure that's the right thing to do.
It muddles the semantics somewhat, and also isn't necessary as the
client & server info are available from other fields.
Hah, you're finding all of the places that I debated with myself for a long time. I ended up adding the orig_h and resp_h for the current connection to the path field because I wanted an easy way to reliably find the address that originally sent the message. If you are watching the actual message being sent from the MUA then it obviously won't have any received headers yet but it was handy to have the orig_h for the connection there anyway.
Do you think we should cut those out? It certainly made log processing easier when I added it.
Hah, you're finding all of the places that I debated with myself for a
long time. I ended up adding the orig_h and resp_h for the current
connection to the path field because I wanted an easy way to reliably
find the address that originally sent the message. If you are watching
the actual message being sent from the MUA then it obviously won't have
any received headers yet but it was handy to have the orig_h for the
connection there anyway.
Do you think we should cut those out? It certainly made log processing
easier when I added it.
Hmmm, I'm somewhat torn. I'm not a big fan of synthesizing information
that looks just like information directly extracted from the application
dialog, but I appreciate your finding that doing so made the log processing
easier. I guess as long as "path" is carefully defined to not suggest
it's simply the overt application dialog, then leaving this as it is seems
okay to me.