On Oct 17, 2006, at 1:22 PM, David B Funk wrote:
BWT, RFC-2821 section 4.4 states that SMTP servers MUST add
"Rececived" headers that indicate the x-fer of the message.
So for your milter to hand a message to SA that lacks the
corresponding
"Received" header cannot be anything but broken.
Uh, actually it would be proper Milter specification. But skip
arguing that. Nobody is arguing that point. Yes, we have to mangle
the input and forge a Received header before sending to you. I've
got that patched now anyway. It's a non-issue.
Yes, because the headers are -supposed- to be the audit-trail that
reports the networks that the SMTP sessions passed thru. These may
have nothing to do with the network that the SA box sits on.
Never seen a forged header in spam, eh? Seriously!!
It is entirely resonable to have a SA scanning "appliance" that has
NO smtp traffic on it, it might even be on a completely different
network from the MTA hosts (the MTAs would be using spamc/spamd
connects
to get the messages to the SA "appliance"). In which case if
SA were to assume that the local interfaces that it can fondle
have anything to do with the mail stream would be seriously broken.
It is reasonable, but it is non-standard and non-guessable. You
wouldn't expect auto detection to figure this out, now would you?
These arguments are getting sillier and sillier. I'm asking why it
doesn't work in a plain-jane do-nothing normal public box not behind
a NAT. And every argument so far has been some strange configuration
that is very customized in various ways.
I believe that autodetection should work properly for NORMAL
configurations, because big appliances are already being tuned by
experts for their needs, and they can configure trusted networks
properly.
Auto-detection is completely broken as it stands. Not because it
doesn't work behind NAT, not because it doesn't work in a custom
environment ... but because it doesn't work for the "normal case"
which is all that you could expect from auto-detection in the first
place.
--
Jo Rhett
Senior Network Engineer
Network Consonance
