On Fri, 2006-06-30 at 18:00 -0400, Daryl C. W. O'Shea wrote: > I'm going to skip to the end pretty quick... where I tell you exactly > the config YOU need (except I don't know your IPs, so you'll have to > fill that in). My setup is a bit more complex than the one described here; I said "assume for simplicity" in the opening just because I'm having trouble even with the simple case.
So I'm still trying to understand the principles. > > Ross Boylan wrote: > > 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." Why doesn't this apply? > > > > 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. Your interpretation of my interpretation, so let's just skip that one. > > > > 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 Since I think one of the real systems I'm dealing with is doing the above, but it's not in this simple example, I'll save that for later. > >> > >> - 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). > > 1 and 3 could apply. 2 might but probably isn't realistic. If I understand what you're saying about the simple example, the machine is acting as an MSA and MTA. Because it's an MTA and MX for my domain, it has to go in trusted and internal_networks. Because it also acts as an MSA, there are two possibilities: a) it breaks the above rule. Then SA's performance will be degraded, because it may flag some internal users as being spammy. b) fix the server or the configuration so one of the above conditions is met. Then things are good. Or, I could just not run SA when I'm getting a message from an authenticated user (I think you mentioned that possibility in an earlier message). (I suppose this technique becomes difficult as the chain gets indirect. In my real situation, for example, an authenticated user sent a message to me at [EMAIL PROTECTED] He connected to the MX a.b.c with an authenticated connection. I then pulled the message down with fetchmail from a.b.c to my box q.r.s. The MTA on my box can not easily tell which messages it pulls in from a.b.c are authenticated and which ones aren't, so I need to have SA able to know what's going on.) So there really is a potential contradiction, because the rules for an MTA as an MX say it must go in internal_networks, while the rules for an MSA says it mustn't unless certain conditions are met (which they are not in the example). > > > > > 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. > > *must* *must* *must* If the server is acting as an MX then it *must* > *must* *must* go in internal networks regardless of anything else. > > > > 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? > > Client means the computer and the associated person that has two legs > and a heartbeat. Does a machine that is not part of my domain qualify as a client? Suppose my MTA is contacted by a dial-up IP for somewhere.com (not my domain), and that I do want to accept such mail. Does that count as "directly accepting mail from client IPs that you WANT to accept mail from"? If it does, then the "internal only if it's not ...." test says the machine is not internal. > > Directly means they send the mail directly to your server (ie. they've > set smtp.your.server.com.org.net.blah. as their outgoing SMTP server in > their mail client). > > In your case (as I now know from below) you've got a combined MX/MSA so > by the rule "the MX is always internal" you *must* satisfy one of my > original three options as quoted above. > The options apply to your own clients, as described immediately above. > Supposing the rule applies only to clients in my domain, it still seem to me the rule "Internal only if it's not directly accepting mail from client IPs that you WANT to accept mail from" still implies a box that does accept direct connections from my clients on dial-up IPs fails this test. So I think you're saying two things: regardless of that rule, "MXes and everything (internal relays) after them are ALWAYS in both trusted and internal networks." (that was the next sentence after the quoted rule--not to mention the *must* *must* *must* earlier!). And, second, if you are in such a situation, you better meet one of the 3 tests of point 3) to avoid degraded SA results. > > > 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. > > If it was just an MSA then it'd only be trusted and not internal. Since > it's also an MX you MUST set it as internal (MXes are *always* internal) > and then satisfy one of the requirements (three options quoted above) > that allow you to include your MSA in the internal network config. > [deletions] Ross
