Slashdot Mirror
GMail and Sourceforge E-mail Bouncing Saga
An anonymous reader writes "All e-mail going back and forth from Sourceforge and Gmail is being bounced. This leaves many Open Source projects with helpless mailing lists. Fortunately, Sourceforge blames Google and Google is blaming SourceForge for this. The Sourceforge support site is clogged with support requests for a resolution to this problem. Google's response to this bouncing has been automated e-mails saying it is probably at the other end of mail delivery. This is something that the community needs to know about since it has been going on for a week already with no end in sight." Worth noting that Sourceforge and Slashdot are both part of OSTG. Update 20:07 GMT by SM: According to SourceForge support staff this issue is now resolved. Apparently a few days ago the sender-verify to gmail started resulting in 450 errors. Google has since either corrected this issue or whitelisted SourceForge and several tests of the system have resulted in correct delivery.
The summary was useless, there's only a few things I want to know about this spat. Who sends the first DSN, why and why was it rejected by the other party?
Why not just dump SourceForge? Surely there are utilities to migrate to another development platform or an open source repository solution...
Sure, there are RFCs and other standards to ensure that if an e-mail isn't delivered, someone is notified, but those are hardly written in stone. Sometimes e-mail just disappears into the wonderful world of dev/null.
There is never, ever any absolute guarantee that an e-mail is going to reach its destination, just as there is no way of knowing if that letter you drop in a mailbox is really going to go where it is supposed to.
If you're trying to maintain a discussion, use a bulletin board. There you can see whether your message was posted, and... as long as the host is up, other people will see what you see.
In any event, people gotta learn that technology is never 100% reliable. You'd think we'd understand this by now.
And now you know why Google is bouncing Sourceforge email.
Or vice versa.
-- Alastair
A pragmatic solution would be to say, "I don't care whose fault it is, we will disable/filter our automatic reply system on our end for a couple days until a real solution can be found." The chances of someone being pragmatic on ONE side is pretty good, and while it wouldn't be necessary, the chances of someone being pragmatic on BOTH sides isn't too terrible to contemplate either.
Once you turn off the water at an upstream valve, fixing the actual pipe rupture gets a lot easier. Just git 'er done.
[
So, it would seem that SourceForge cannot verify the sender of incoming messages from GMail so SourceForge is issuing a temporary rejection.
Is GMail correctly handling the temp rejects?
The solution would be:
a. Find out where the sender verify callout is breaking and fix that.
b. Disable sender verify callout until you can do "a".
Initially callbacks will be evil as you say. But if gmail implements a learning system and starts tagging which ip addresses in the call chain are routinely sending spam it can become better. So at some point it will detect spam without actually calling back. So give them some slack please.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
--- SER
Lets be realistic here, google has a fantastic track record of impementing huge computer systems, and sourceforge is a bunch of kids in some basement.
SourceForge doesn't use Mailman - as an MTA. Instead, Mailman re-sends messages using their main MTA, probably Sendmail or Postfix (I'm too lazy to look). In other words, Mailman never connects directly to the GMail servers, so I'd be extremely hesitant to blame it.
Dewey, what part of this looks like authorities should be involved?
I get all my messages delivered to my Gmail account from Sourceforge. but I can't post. The problem is clearly that Sourceforge.net is doing SMTP callbacks in ways that are not RFC compliant. Note that I can post with mail2web but not my own Qmail server.
This is pure and simple a problem with poorly orchestrated spam controls on SF.Net's side.
LedgerSMB: Open source Accounting/ERP
Yes, it was a coding mistake.
It appeared to work in all test cases we came across.
liqbase