Well, I've obviously missed something. In this message I will focus exclusively on the question of whether a host that receives messages from dial-up hosts should go on internal_networks. Assume for simplicity I have a mail domain b.c. The MX records point to a.b.c. I'm running SA on a.b.c for messages it receives. It might be at SMTP time (in which case I don't think the received header for a.b.c is in the message yet) or later.
Also, I'm talking about messages received from the internet at large, not from my own users. Here's why I thought such a host did not go on internal_networks: ================================================================ 1) Mail::SpamAssassin:Conf says "Trusted relays that accept mail directly from dial-up connections should not be listed in internal_networks." 2) My original post and the first reply were >> [Ross] here's what I think it is: >> trusted_networks for hosts I trust to put good info in the Received >> headers. >> internal_networks for those that are additionally trusted not to >> receive email from IP's in dial-up RBL's. >> >> Is that about right? > [Daryl] Yeah, that's pretty good. 3) > [Daryl] You can not add your MSA to your internal_networks unless you > can do one of the following: > > - have all your MSA users use SMTP auth AND use mail server software > that includes RFC 3848 or Sendmail-style auth tokens in it's received > headers > > - include ALL of your MSA users' IP addresses in your trusted_networks > and internal_networks -- you can only do this if you control all of > the IP space in question and never have roaming users sending mail > from remote IP space (which is nearly never the case) > > - use the POPAuth plugin to extend trusted_networks to POP-before-SMTP > clients if you use POP-before-SMTP for user authentication > Note: Only configure trusted_networks if you're using this plugin, > do not configure internal_networks > Since I'm accepting mail from the internet at large, it doesn't seem any of these apply, and so the machine should not be on internal_networks. It is true the machine is picky about who it will send mail to the internet on behalf of (namely, on itself in this simple case). And here's why it now seems such a host should go on internal_networks: ====================================================================== 10) > [Daryl] If this is the case (the server is acting as an MX for you -- > it'd be listed in one of your MX records) then you must include it in > both your trusted and internal networks. 11) > > [Ross] I thought it was internal only if I was sure it wasn't > > accepting mail > > from questionable IP's, and I'm not. > > [Daryl] No. Internal only if it's not directly accepting mail from client > IPs > that you WANT to accept mail from. MXes and everything (internal > relays) after them are ALWAYS in both trusted and internal networks. > > This is what tells SA that mail was sent directly from "questionable > IPs" to your systems. It sees that some (questionable) IP sent mail to > an internal host without going through some external host first. > So, in the situation above, is my system "directly accepting mail from client IPs that you WANT to accept mail from"? I'm not sure of the significance of the words "directly" or "client". In particular, does "client" mean client as in client/server, in which case any system contacting my server is a client, or something more specific? And does "direct" somehow refer to the distinct roles my mail server plays (see point 20 below), even though it's one program? My reading is that the server directly accepts all connections, so it fails this test and doesn't belong in internal_networks. But that's clearly not the intended meaning. 12) [Daryl] > To be clear though, there is ALWAYS at least one host listed in your > internal_networks. Always. That's easy: there is only one host I might list here, so clearly this means I do list it. 13) [Daryl] > No. a.b.edu is an MX. ALL MXes MUST be in both trusted and internal > networks. I assume that means all *my* MXes. Finally, there was something that just puzzled me: ================================================= 20) > > >[Daryl] You don't receive mail from smarthosts and smarthosts don't > > >handle mail for domains. > > [Ross] Well, the same machine that is acting as a smarthost for my outbound > > mail is also receiving mail for me. > > [Daryl] Yeah one physical server, many logical services. For such a server > you > MUST conform to one of the three options outlined in my original email. Those are the points in item 3) above. This means the server must conform for SA to work? It must conform for SA to work optimally? It must conform to be a good internet citizen (not an open relay)? What if it doesn't conform? Some of the options seem to refer to the setup of the mail server itself (the first option), while some refer to the configuration of SA (the last 2 options). In the same vein, Daryl wrote > If a.b.edu also acts as an MSA for people then your config or that > host must conform to one of the three options originally noted. Conclusion ========== So how can all the previous items (removing my interpretations) be true? I think I may be missing some distinction between MX, MTA, MSA, and relay, which I tend to collapse since the same box and the same program (exim) is performing all these roles. In particular, I'm not familiar with the concept of an MSA. Should I think MTA when mail comes from the internet to my system, and MSA when it goes from my system to the internet? What about mail entirely within my system? P.S. What does FP mean? Spam points?
