Jo Rhett wrote:
Matt Kettler wrote:
Matt Kettler wrote:
So perhaps I didn't get the Received header that will be added by this
host.
Yeah, so how did it get to SA? That's the problem. How can SA be
scanning it, if it hasn't reached this host yet?
Does this matter? SA *IS* scanning it, and for unknown reasons
assigning the random remote host as trusted. That is *BROKEN*.
As I've said before, YES, it does matter.
SA knows *nothing* about the connection that isn't in the headers. In
your example in this thread you had two headers, one that was added
after SA saw it, and one that came in as DATA.
As stated in the documentation, SA *requires* you to at least forge a
received header for the local relay before passing the mail to SA. This
is the only way that SA can gather data about the connection, the
envelope, etc.
If you were to be doing what is *required*, SA would see this forged
received header, assume that it is the local trusted server (like the
docs says it will do). It'll then compare the IP addr info from the
first forged received header to the one supplied by the remote host and
see that it is not trusted and won't trust it -- just like you're
bitching that it's not doing because you're not providing the correct
input to SA.
What kind of logic says that it should trust a remote IP from a very
random source that isn't authenticated by a local header?
Because it's equally absurd to assume that the most recent header isn't
local.
I'm sorry, but phrases like "what are you babbling about" keep floating
to the top of my mind when I read your response. (sorry, need more
coffee) Your logic appears to be backwards -- if the results are
confusing, assume trusted?
The application's documentation requires you to ensure that the first
received header it sees is local. It'd be awfully stupid if we required
the first header was local and then assumed it was remote just for the
hell of it.
The only flawed logic I see here is you expecting incorrect input to
lead to correct output (not that the output is wrong given the input, of
course).
Slow down and explain to me exactly why the most recent header having a
remote address in it should be trusted?
I've already told you this before, and again above. You are required to
ensure that the most recent received header is local. Maybe we're at
fault assuming that the user is going to call the application according
to the documentation.
Seriously, I can't figure out what you think should be happening. None
of these sites are local. None of them are even in the same /8 network.
Why does autodetection decide that they are trusted?
I've only seen examples from you that include only one received header
that was actually presented to SA (which thus must be assumed to be
local), so I have no idea what you're saying isn't working here.
Anyway... that's it from me, at least until you start calling SA
correctly. Until you fix your milter and can demonstrate otherwise I
maintain that the auto-detection works as documented.
Daryl
