af3556 Posted October 22, 2004 Share Posted October 22, 2004 Hello, My organisation runs a tiered mail infrastructure (public and private front-ends followed by an AV/spam filter pool and a distribution (spool) pool). Ultimately this appears as multiple Received lines in mail delivered to users. Of course, an unfortunate quantity of that mail is spam, and some of our users dutifully report such spam to SpamCop. Unfortunately our implementation does not follow SpamCop's chain-test heuristic, and our internal servers thus get (mis)identified as the spam source. e.g.: http://www.spamcop.net/sc?id=z684528486zee...0df7569e93b626z As the forwarding rules are an internal policy, SpamCop cannot use MX records to validate the mail chain. According to the FAQ [1], SC will then use a heuristic to determine if the chain is "reasonable". The FAQ says it checks for a common 2nd level domain (though I expect it really means a consistent parent domain?). Our internal mail processors are in a twice-removed subdomain (e.g. smtp-dist-02.SERVICES.COMMS.unsw.edu.au) compared to our public MX (smtp.unsw.edu.au). As our network address allocations are not based on /24 blocks, the constraint of being in the same /24 is also not met. So, our implementation is evidently not SC-friendly. My question is: if we move our internal servers into the unsw.edu.au domain (e.g. smtp-dist-02.unsw.edu.au), will this alone be enough for SC to grok our forwarding chain? Or do we also need to rearrange our network address allocations? The FAQ explanation is not entirely clear to me here, especially as the SC report (linked above) notes "...[our servers] have same domain - chain verified": ... Received: from cust239.209.188.70.dsl.accessv.com (cust239.209.188.70.dsl.accessv.com [209.188.70.239]) by smtp.unsw.edu.au (8.13.1/8.13.1) with SMTP id i9LBDGlo010528 for <x>; Thu, 21 Oct 2004 21:13:24 +1000 (EST) Possible untrusted IP in HELO name, removing: 239.209.188.70 Received: from x (cust239.209.188.70.dsl.accessv.com [209.188.70.239]) by smtp.unsw.edu.au (8.13.1/8.13.1) with SMTP id i9LBDGlo010528 for <x>; Thu, 21 Oct 2004 21:13:24 +1000 (EST) … snip … Chain test:smtp.unsw.edu.au =? avspam-01.services.comms.unsw.edu.au host avspam-01.services.comms.unsw.edu.au (checking ip) = 149.171.100.16 149.171.100.16 is not an MX for smtp.unsw.edu.au host smtp.unsw.edu.au (checking ip) = 149.171.193.32 149.171.100.16 is not an MX for smtp.unsw.edu.au smtp.unsw.edu.au and avspam-01.services.comms.unsw.edu.au have same domain - chain verified Possible relay: 149.171.100.16 … snip ... As an aside: installing MX records for the internal servers is not a practical option for us as each layer contains a number of servers in a pool (load-balanced by the network, not DNS), which means managing and maintaining NxM records at each stage. For a smaller-scale environment, is using MX record "pointers" considered the "best" solution to help SC validate the forwarding chain? [1] "Why does SpamCop want to send a report to my own network administrator?" http://www.spamcop.net/fom-serve/cache/13.html Regards, Ben Low Link to comment Share on other sites More sharing options...
Wazoo Posted October 22, 2004 Share Posted October 22, 2004 First of all .. what a mess .... However, item #1 ... first impression is that "your" reporter is not living up to his/her part of the agreement entered into when signing up for a SpamCop account. The appearance is that this is a reporter that just submits the spam and blindly clicks on the "Send Reports Now" button. You can complain, this user gets "fined" if a paying user, banned if a free user. The Tracking URL you provided is currently showing a bit different results than the orginal reporter appaerntly received. One "guess" is that the servers in this mess fall into the "recently discovered" mode ... but enough data has been gained by the parser/database that it is now somewhat "trusted" .... (again, only a guess at this point) Reports regarding this spam have already been sent: Re: 149.171.100.16 (Administrator of network where email originates) Reportid: 1270264560 To: abuse[at]unsw.edu.au Reportid: 1270264561 To: spamcop[at]imaphost.com If reported today, reports would be sent to: Re: 209.188.70.239 (Administrator of network where email originates) postmaster[at]accessv.com Re: 209.188.70.239 (Third party interested in email source) spamcop[at]imaphost.com One of the real issues in your sample is that the handoff between smtp.unsw.edu.au and smtp-dist.unsw.edu.au is not actually "there" .... the system localhost (avspam-01.services.comms.unsw.edu.au just kind of pops out of nowhere in the middle of this chain. The "explanation" of the chain test is better seen in looking at the parsing results (with Technical Details turned on) .... all the "domain matches" stuff is due to the MX recordes not existing. At any rate, if you look at the data in the provided Tracking URL, though you are beating the heck out of the parsing engine trying to work out the references, you'll note that it actually does make it past your servers (now) I'd say your next action item would be to talk to the reporter of this spam. Link to comment Share on other sites More sharing options...
turetzsr Posted October 22, 2004 Share Posted October 22, 2004 Hello, My organisation runs a tiered mail infrastructure (public and private front-ends followed by an AV/spam filter pool and a distribution (spool) pool). Ultimately this appears as multiple Received lines in mail delivered to users. Of course, an unfortunate quantity of that mail is spam, and some of our users dutifully report such spam to SpamCop. Unfortunately our implementation does not follow SpamCop's chain-test heuristic, and our internal servers thus get (mis)identified as the spam source. <snip> [1] "Why does SpamCop want to send a report to my own network administrator?" http://www.spamcop.net/fom-serve/cache/13.html Regards, Ben Low 19120[/snapback] ...Ben: thank you for reading the FAQ before posting! <snip> However, item #1 ... first impression is that "your" reporter is not living up to his/her part of the agreement entered into when signing up for a SpamCop account. The appearance is that this is a reporter that just submits the spam and blindly clicks on the "Send Reports Now" button. You can complain, this user gets "fined" if a paying user, banned if a free user. <snip> 19123[/snapback] ...That may be a bit strong -- hopefully, SpamCop admins are a little bit forgiving, at least of first (and maybe even second) offenses. <g> Link to comment Share on other sites More sharing options...
af3556 Posted October 24, 2004 Author Share Posted October 24, 2004 G Link to comment Share on other sites More sharing options...
af3556 Posted October 25, 2004 Author Share Posted October 25, 2004 [what happened to my previous post? (my whole message turned into "G"!)] G'Day Wazoo, ... the appearance is that this is a reporter that just submits the spam and blindly clicks on the "Send Reports Now" button ... For better or worse, the vast majority of our users don't know how to do much else. Also, as a university we do get a lot of spam generated from the inside (almost always zombie windows boxes running amok before we can toast them), so our users can't simply assume "inside == not spam". In this case I've spoken to the user, apparently they did think before sending the report but didn't pick up the problem. ... One of the real issues in your sample is that the handoff between smtp.unsw.edu.au and smtp-dist.unsw.edu.au is not actually "there" .... the system localhost (avspam-01.services.comms.unsw.edu.au just kind of pops out of nowhere in the middle of this chain. ... 19123[/snapback] So would cleaning up our DNS naming conventions be enough to make those steps easier for SC to parse ? Or would we need to do more / something else? Thanks, Ben Link to comment Share on other sites More sharing options...
Ellen Posted October 26, 2004 Share Posted October 26, 2004 Send me a list of the server IPs that you use -- include the internal ones -- and I'll flag them all as valid mailservers. Link to comment Share on other sites More sharing options...
Jeff G. Posted October 30, 2004 Share Posted October 30, 2004 Send me a list of the server IPs that you use -- include the internal ones -- and I'll flag them all as valid mailservers. 19222[/snapback] This appears to have been done, as both 149.171.97.17 and 149.171.100.16 are now "trusted". Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.