Jo Rhett wrote: > Matt Kettler wrote: >>> Matt Kettler wrote: >>>> YOUR network is broken because YOUR network doesn't add Received: >>>> headers before calling SA.. That's not EVERYONE, that's YOU. >>>> >>>> Get your tools to add a local Received: header before you call SA, the >>>> auto-detection code will start working. >>>> >>>> After all, if you haven't Received: the message yet, how'd it get >>>> to SA? >>>> Do your really expect SA to work on a message that doesn't even appear >>>> to have been delivered to your domain yet? > >> Jo Rhett wrote: >>> As mentioned in my previous message, I have dozens of messages here >>> that have as many as 12 received headers. > >> Yes, but none are LOCAL. > > RIGHT. So why are they Trusted? > Because there *HAS* to be a local. If there isn't, then the message isn't at your server.
This is the whole point. If the message hasn't been Received: by a local server, it is by definition not in your network. By feeding messages to SA without a local Received: header, you are explicitly telling SA that the message is still in some other network, not yours. So what's SA supposed to do? Is SA supposed to know that the message magically appeared in your mail systems despite never being recorded as Received by them? What should SA do if a message is being direct-delivered and has no existing Recived: headers in it? Where should it decide the message came from? Look, here's a message that got here from nowhere. It wasn't even sent by the localhost, it just spontaneously appeared in the mail system. Nobody sent it, nobody Received it, it just appeared here. This whole scenario is ridiculous.. OF COURSE spamassassin will break when you feed it this. It can't possibly even TRY to make sense of it because required records are missing. How could SA behave properly in this case? What should it do? Should SA inherently assume that some magic exists where messages can magically poof from one mail queue to the next without ever being transmitted over a mail transport protocol? Should it assume hackers have taken over your server and are directly inserting messages into your system without going through your MTA (ie: writing queue files directly?) Or should it just misbehave so hopefully the admin realizes he needs to FIX a BROKEN SERVER. > > Does this matter? YES IT DOES! Sa makes basic assumptions about REALITY. Messages get transmitted over the internet between mailservers. Durring this process, Received: headers are added as per RFC requirements for SMTP. SA depends on Received: those records generated by your own network. When your network is broken, SA becomes broken, but why would you ever not add a Received: header? The problem isn't SA breaking, it's the fact that a RFC required piece of information is missing from the message. > SA *IS* scanning it, and for unknown reasons assigning the random > remote host as trusted. That is *BROKEN*. No, trying to pretend the message hasn't arrived at your server when it has is BROKEN. Look, I have this message, but it hasn't gotten here yet.. What??? Look, I agree, the trust path code breaks when you give it GARBAGE NONSENSE as input. Fine. Garbage in, Garbage out. It's complete insanity to try to expect SA to behave properly without a local Received: header. And the trust path isn't the only thing that breaks. It's just one of DOZENS of problems. All your RBL checks, SPF checks, DomainKeys, HELO_DYNAMIC rules, whitelist_from_rcvd, they're all going to be completely and hopelessly broken. Why? Because SA doesn't know how the message got to your network, there's no record of it. It's missing.
