Re: spamd shows up as an open relay
> I'm not 100% certain I'm "get"ting your idea here ... we do currently > run inbound/outbound mail on different IPs, but the problem isn't with > the connections themselves. > > From the example session transcript with spamd that I posted earlier: > > 250 Hello, spam sender. Pleased to be wasting your time. > MAIL FROM: [EMAIL PROTECTED] > 250 Ok to start over. > RCPT TO: [EMAIL PROTECTED] > 250 You are about to try to deliver spam. Your time will be spent, for > nothing. > > For an actual MTA, the 250 code here indicates an open relay, because > we are not the MX for checkor.com. Nope, because you can reject it later on. Their test is flawed. All our open relay checking we do here actually checks the full dialogue to see if the message is accepted *and* checks for an actual relay, if they aren't doing that, their test is amatuer hour crap. > spamd of course doesn't know this > (and I'm aware that fixing it might not be easy), but it is still > triggering a false positive as an open relay. Spamd won't change in this regard. It would completely break spamd to accomodate some false idea of a "test".
Re: spamd shows up as an open relay
hmm, on Wed, Sep 26, 2007 at 11:22:23AM +0200, frantisek holop said that > dnsstuff.com is great to have a look what an admin > left out/forgot/doesn't know :D > > i was quite dismayed too when it showed me as an open relay... > (http://www.dnsstuff.com/tools/dnsreport.ch?domain=obiit.org) sorry, doesn't let you use it directly, doh. have to go through the front door. and when you pass that test, they'll say, it's just a quick check, and go to http://www.abuse.net/relay.html if want a full check. -f -- 30 minutes of begging is not considered foreplay.
Re: spamd shows up as an open relay
hmm, on Tue, Sep 25, 2007 at 02:50:41PM -0700, Rob said that > We just ran across an odd intermittent problem with email that we > traced back to spamd showing up as an open relay. I double-checked the > documentation and mailing list archives and didn't find anything > relevant. dnsstuff.com is great to have a look what an admin left out/forgot/doesn't know :D i was quite dismayed too when it showed me as an open relay... (http://www.dnsstuff.com/tools/dnsreport.ch?domain=obiit.org) but please note their wording: FAIL Open relay test WARNING: One or more of your mailservers appears to be an open relay. If so, this means that you are allowing spammers to freely use the mailserver to send out spam! It is possible that your mailserver accepts all E-mail and later bounces it, or accepts the relay attempt and then deletes the E-mail, but this is not common. WARNING: obiit.org appears to be an open relay: 250 This is hurting you more than it is hurting me. and they are right, it is not common. but any service that would rely on this kind of info _only_ (mail accepted but not checking if arrived) should get a clue and rethink their strategy. that said, i have no idea if this could be changed in a meaningful way for spamd. the best thing about it after all, is it's MTA/OS ignorance. -f -- 43.3% of all statistics are meaningless.
Re: spamd shows up as an open relay
Rob wrote: You're right, then. If I explicitly block inbound connections to the outbound mail server (instead of redirecting them), that might fix the problem ... depending on just what kind of check the recipient's mail server is doing. A sending MTA is not required to accept SMTP connections, only those listed with DNS MX records should do so. I guess the superfluous redirect is causing the trouble. The outbound server must TCP block inbound connections with pf or the OS, do not use the MTA to 55x reject the connection. Slightly off topic; but as you know, sender verification schemes work by looking up the sender's domain's MX records and attempting to "send" a mail to that sender. Should not matter which IP the mail is coming from. Compare gmail's vast array of outbound MTA ip address blocks, they are not listed in the MX records. I'm a little concerned about just blocking those connections per your suggestion, though. Sounds like the right thing to do to me. It might end up just changing the affected recipients; if someone's dumb enough not to correctly check for an open relay, someone else is certainly dumb enough to reject mail if they can't connect back to the inbound IP. But you said that they are connecting to the outbound IP and that you are redirecting them to the inbound IP, so this is not an issue if you reject the connection instead of redirecting it. Best you can do is give it a go and send them a mail while watching the logs! Its only mail, not as if gold bullion is getting lost.
Re: spamd shows up as an open relay
On 9/26/07, Rob <[EMAIL PROTECTED]> wrote: > Yeah, I agree. It's the wrong way for them to check for an open relay, > but it is still causing a bit of a problem. Well if it is actually caused by spamd you have 2 options: a) not run spamd. b) ask them to get their shit together and hope they actually do. It's amazing that in 2007 there are still so many mail operators and relay-check sites that doesn't have a clue. --- Lars Hansson
Re: spamd shows up as an open relay
On 9/25/07, Stuart Henderson <[EMAIL PROTECTED]> wrote: > On 2007/09/25 17:35, Rob wrote: > > Since this is happening during the conversation with our inbound mail > > server, I don't see how filtering connections between our inbound and > > outbound mail servers would fix it. > > From what you say, it sounds like your outbound mail server sends > mail to some host which carries out an on-the-fly relay test, is that > right? Ah, gotcha. That's basically correct. Our user sends email to the outbound mail server, which connects to the recipient's mail server. The problem is, if the recipient's mail server is performing an on-the-fly check, then its connection back to our outbound mail server would automatically be redirected to our inbound mail server, which gets intercepted by spamd, which appears to be the open relay. You're right, then. If I explicitly block inbound connections to the outbound mail server (instead of redirecting them), that might fix the problem ... depending on just what kind of check the recipient's mail server is doing. > If so, surely they only test the host *sending* the mail to them? I don't know yet exactly what they do. I'm crawling my way up their support ladder to try to figure it out. They could be doing some kind of open relay greylisting, or who-knows-what. I'm a little concerned about just blocking those connections per your suggestion, though. It might end up just changing the affected recipients; if someone's dumb enough not to correctly check for an open relay, someone else is certainly dumb enough to reject mail if they can't connect back to the inbound IP. - R.
Re: spamd shows up as an open relay
On 2007/09/25 17:35, Rob wrote: > Since this is happening during the conversation with our inbound mail > server, I don't see how filtering connections between our inbound and > outbound mail servers would fix it. >From what you say, it sounds like your outbound mail server sends mail to some host which carries out an on-the-fly relay test, is that right? If so, surely they only test the host *sending* the mail to them?
Re: spamd shows up as an open relay
I'm not 100% certain I'm "get"ting your idea here ... we do currently run inbound/outbound mail on different IPs, but the problem isn't with the connections themselves. >From the example session transcript with spamd that I posted earlier: 250 Hello, spam sender. Pleased to be wasting your time. MAIL FROM: [EMAIL PROTECTED] 250 Ok to start over. RCPT TO: [EMAIL PROTECTED] 250 You are about to try to deliver spam. Your time will be spent, for nothing. For an actual MTA, the 250 code here indicates an open relay, because we are not the MX for checkor.com. spamd of course doesn't know this (and I'm aware that fixing it might not be easy), but it is still triggering a false positive as an open relay. Since this is happening during the conversation with our inbound mail server, I don't see how filtering connections between our inbound and outbound mail servers would fix it. Thanks, - R. On 9/25/07, Stuart Henderson <[EMAIL PROTECTED]> wrote: > On 2007/09/25 14:50, Rob wrote: > > > > Is there some configuration for spamd that I've missed > > You could run inbound and outbound email on different IP addresses, > and don't accept incoming port 25 connections on the address used as > a source for outgoing mail.
Re: spamd shows up as an open relay
On 2007/09/25 14:50, Rob wrote: > > Is there some configuration for spamd that I've missed You could run inbound and outbound email on different IP addresses, and don't accept incoming port 25 connections on the address used as a source for outgoing mail.
Re: spamd shows up as an open relay
Hi Jeremy, On 9/25/07, Jeremy C. Reed <[EMAIL PROTECTED]> wrote: > On Tue, 25 Sep 2007, Rob wrote: > > > We just ran across an odd intermittent problem with email that we > > traced back to spamd showing up as an open relay. I double-checked the > > documentation and mailing list archives and didn't find anything > > relevant. > > Please let us know what service (if different thatn No-IP/CheckOR.com) > that had you listed. Was it a dnsbl service? We haven't been listed by any DNSBLs. It looks like it's just some -- a few? big? small? -- service providers that are doing some kind of check against our mail server, finding it behaving like an open relay, and routing mail from our mail server to their users' junk folders. I'll reply back shortly with the name of a specific provider. > > Some sample results from http://www.checkor.com/: > > They assume it is an open relay even though nothing was relayed. More > accurate relay checks attempt to relay to themselves to verify. Yeah, I agree. It's the wrong way for them to check for an open relay, but it is still causing a bit of a problem. - R.
Re: spamd shows up as an open relay
On Tue, 25 Sep 2007, Rob wrote: > We just ran across an odd intermittent problem with email that we > traced back to spamd showing up as an open relay. I double-checked the > documentation and mailing list archives and didn't find anything > relevant. Please let us know what service (if different thatn No-IP/CheckOR.com) that had you listed. Was it a dnsbl service? > Some sample results from http://www.checkor.com/: They assume it is an open relay even though nothing was relayed. More accurate relay checks attempt to relay to themselves to verify. Jeremy C. Reed
spamd shows up as an open relay
Hey guys, We just ran across an odd intermittent problem with email that we traced back to spamd showing up as an open relay. I double-checked the documentation and mailing list archives and didn't find anything relevant. Our mail server is bara.nccn.net, 12.165.58.50. There is a bump-in-the-wire firewall sitting in front of bara, running OpenBSD + spamd and a few other goodies. spamd is configured to intercept incoming smtp connections in the usual way in pf. Some sample results from http://www.checkor.com/: RSET 250 Hello, spam sender. Pleased to be wasting your time. MAIL FROM: [EMAIL PROTECTED] 250 Ok to start over. RCPT TO: [EMAIL PROTECTED] Test Failed, 250 You are about to try to deliver spam. Your time will be spent, for nothing. and RSET 250 This is hurting you more than it is hurting me. MAIL FROM: [EMAIL PROTECTED] 250 Ok to start over. RCPT TO: @12.165.58.50:[EMAIL PROTECTED] Test Failed, 250 You are about to try to deliver spam. Your time will be spent, for nothing. and RSET 250 This is hurting you more than it is hurting me. MAIL FROM: [EMAIL PROTECTED] 250 Ok to start over. RCPT TO: "[EMAIL PROTECTED]"@12.165.58.50 Test Failed, 250 You are about to try to deliver spam. Your time will be spent, for nothing. and RSET 250 This is hurting you more than it is hurting me. MAIL FROM: [EMAIL PROTECTED] 250 Ok to start over. RCPT TO: [EMAIL PROTECTED] Test Failed, 250 You are about to try to deliver spam. Your time will be spent, for nothing. This is causing some of our outbound email to end up in other peoples' junk boxes by default by large service providers (oops). Is there some configuration for spamd that I've missed, or is it going to require a patch to fix the way it handles mail from/rcpt to, or is there another workaround? Thanks, - R.