GMail and Sourceforge E-mail Bouncing Saga 242
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.
Probably Sourceforge? (Score:5, Informative)
SourceForge is good for spewing into the ether... (Score:5, Informative)
Re:Umm (Score:5, Informative)
SPF records.... (Score:4, Informative)
It's neither sourceforge's fault not google's fault. It's the enduser's fault. You must send/receive email through google's gmail system.
You get what you pay for.....
Re:Why is the email bouncing? (Score:2, Informative)
TEMP_FAILURE: SMTP Error (state 9): 451-Could not complete
sender verify callout
451-Could not complete sender verify callout for
.
451-The mail server(s) for the domain may be temporarily
unreachable, or
451-they may be permanently unreachable from this server. In
the latter case,
451-you need to change the address or create an MX record
for its domain
451-if it is supposed to be generally accessible from the
Internet.
451 Talk to your mail administrator for details.
I beg to differ (Score:5, Informative)
Of course, this is the sort of accuracy I expect from Slashdot.
Callbacks Are Evil (Score:3, Informative)
Gmail is initiating what are called call-backs. For every incoming e-mail, they attempt to send a fake e-mail back to the sender to verify that the sending address actually exists.
The theory is that since spammers forge many names, it will reject spams that have made up names forged into them.
The end result, however, is that it pushes your spam problem back on to the domain forged into the spam. It causes an extra load on that server as it has to accept all these bogus connections. For another it will just encourage spammers to forge other people's actual addresses as the sender of their garbage.
It is encouraging to see that Sourceforge does not support that. I would give the solution as to either complain to Gmail that callbacks break they stated goal of "Do no evil".
Barring that, don't use gmail.
You have never had experience with this problem... (Score:3, Informative)
It is a *very serious* problem for Sourceforge. Before all this happened, we were actually talking about using Google Code instead.
If you are interested in what LedgerSMB [ledgersmb.org] is, it is a truly open fork of SQL-Ledger with a real attention to security and data integrity. Currently we offer a more secure system with a few additional features and reports. But we already have a number of new features committed to SVN such as a framework for real-time credit card processing (for POS applications) and the like.
Re:Can you expand on this a bit? (Score:4, Informative)
Includes web space, svn hosting, a tracker, and the like.
It is definitely Sourceforge's problem (Score:5, Informative)
Greetings,
We're aware of the difficulties in the interaction
between
our mailing list services and Gmail. Our network operations
team
is currently aware of the issue and is working with Gmail
administration on a resolution.
-Jay Bonci
Systems Programmer Analyst,
Sourceforge.net
Somebody posted a SMTP dialog to one of the bug reports:
Example:
telnet mail.sourceforge.net 25
Trying 66.35.250.206...
Connected to mail.sourceforge.net.
Escape character is '^]'.
220 mail.sourceforge.net ESMTP Exim 4.44 Sat, 30 Sep
2006 01:12:02 -0700 sc8-sf-mx1.sourceforge.net
HELO aisa.fi.muni.cz
250 mail.sourceforge.net Hello 14397 at aisa.fi.muni.cz [147.251.48.1]
mail from:
250 OK
rcpt to:
451-Could not complete sender verify callout
451-Could not complete sender verify callout for <anyone@gmail.com>
451-The mail server(s) for the domain may be temporarily unreachable, or
451-they may be permanently unreachable from this server. In the latter case,
451-you need to change the address or create an MX record for its domain
451-if it is supposed to be generally accessible from the Internet.
451 Talk to your mail administrator for details.
QUIT
221 mail.sourceforge.net closing connection
Connection closed by foreign host.
Sourceforge's mail server is doing a callback to gmail.com, to verify the sender address is accepted by gmail.com. This check is screwing up. It's Sourceforge's problem. Callback verify is not covered by any RFC, so SF has gone above and beyond the standards, it is their responsibility to make sure their SMTP service is interoperable with standard servers, not the other way around. Google can provide logs of the failed callbacks, but that's all the burden they should assume. It's SF's problem to fix.
Re:It is definitely Sourceforge's problem (Score:3, Informative)
mail from: <anyone@gmail.com>
250 OK
rcpt to: <firebird-net-provider@lists.sourceforge.net>
451-Could not complete sender verify callout
451-Could not complete sender verify callout for <anyone@gmail.com>
451-The mail server(s) for the domain may be temporarily unreachable, or
451-they may be permanently unreachable from this server. In the latter case,
451-you need to change the address or create an MX record for its domain
451-if it is supposed to be generally accessible from the Internet.
451 Talk to your mail administrator for details.
QUIT
221 mail.sourceforge.net closing connection
Connection closed by foreign host.
Once again, this is Sourceforge's problem. They are delaying mail on account of a broken callback, they need to fix it, nothing is wrong with Gmail.
Re:It is definitely Sourceforge's problem (Score:4, Informative)
On the other hand, there is nothing in any RFC that prohibits you from doing callbacks.
Unfortunately the above post misses critical information about the callback itself. What mail address is it using as a source?
Usually, callbacks use "MAIL FROM:<>" and the RFCs explicitly state that you MUST accept this. But, some mailservers reject mail from <>. That could be a problem, but in this case the problem is in the called server that does not implement a MUST item.
The mailserver I manage at work uses callbacks. It almost never causes problems. In cases where the sending server refuses MAIL FROM:<> it tries to use MAIL FROM:<mailer-daemon@domain>.
The only known problem occurs when the called server first accepts MAIL FROM:<> and then rejects the RCPT TO: with an error referring back to the <> source.
This is done by the broken "Spamfilter for ISP" by LOGSAT. But this one has other SMTP protocol bugs, so just don't use it.
And then of course there are some mailinglists that simply send their mail from a nonexistant address. Presumably to avoid having to do list maintenance.
I consider this antisocial, and have no problem with blocking their mail.
Re:Why is the email bouncing? (Score:5, Informative)
X-Gmail-Received: ecfafb0784517c3cc7f903105542834cd33fde22
Delivered-To: rodolfo.borges@gmail.com
Received: by 10.35.42.5 with SMTP id u5cs205830pyj;
Sat, 30 Sep 2006 21:26:16 -0700 (PDT)
Received: by 10.35.61.2 with SMTP id o2mr4364526pyk;
Sat, 30 Sep 2006 21:26:16 -0700 (PDT)
Return-Path:
Received: by 10.35.61.2 with SMTP id o2mr5005562pyk;
Sat, 30 Sep 2006 21:26:16 -0700 (PDT)
From: Mail Delivery Subsystem
To: rodolfo.borges@gmail.com
Subject: Delivery Status Notification (Delay)
Date: Sat, 30 Sep 2006 21:26:16 -0700 (PDT)
This is an automatically generated Delivery Status Notification
THIS IS A WARNING MESSAGE ONLY.
YOU DO NOT NEED TO RESEND YOUR MESSAGE.
Delivery to the following recipient has been delayed:
albert@users.sf.net
Message will be retried for 2 more day(s)
Technical details of temporary failure:
TEMP_FAILURE: SMTP Error (state 9): 451-Could not complete sender verify callout
451-Could not complete sender verify callout for .
451-The mail server(s) for the domain may be temporarily unreachable, or
451-they may be permanently unreachable from this server. In the latter case,
451-you need to change the address or create an MX record for its domain
451-if it is supposed to be generally accessible from the Internet.
451 Talk to your mail administrator for details.
----- Message header follows -----
Received: by 10.35.61.2 with SMTP id o2mr1893905pyk;
Fri, 29 Sep 2006 20:41:07 -0700 (PDT)
Received: by 10.35.42.5 with HTTP; Fri, 29 Sep 2006 20:41:07 -0700 (PDT)
Message-ID:
Date: Sat, 30 Sep 2006 00:41:07 -0300
From: "Rodolfo Borges"
To: procps-feedback@lists.sf.net
Subject: pkill -l
Cc: "Kjetil Torgrim Homme" ,
"Albert Cahalan"
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
----- Message body suppressed -----
Re:Loss of communication can only mean one thing.. (Score:4, Informative)
A communications disruption can mean only one thing - invasion. [moviewavs.com] (MP3) [moviewavs.com]
Re:SPF records.... (Score:5, Informative)
SPF has nothing to do with it. Sourceforge is employing callback verification, which is not only abuse itself (it's basically a dictionary attack that we're just supposed to trust is for good and not evil), it's also incredibly broken.
See http://atm.tut.fi/list-archive/nanog/msg37172.htm
Just one more reason to jump ship from sourceforget.
Re:SPF records.... (Score:3, Informative)
That's not the case here. I use gmail solely through the web interface, nothing fancy going on at all. I'm subscribed to my SF.NET mailing lists at the same address I'm sending from. But my mail is bouncing. And this has been going on for a week now, since last Wednesday.
If it is an SPF problem, then one of the two of them is implementing it wrong, because all gmail users are affected, including ones like me who use gmail as a simple webmail account.
hosted gmail (Score:4, Informative)
Re:SPF records.... (Score:2, Informative)
_spf.google.com descriptive text "v=spf1 ip4:216.239.56.0/23 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ?all"
the ?all at the end means that their is no policy how forged mail is going to be handled by SPF aware MTAs and defaults to accept.
see http://en.wikipedia.org/wiki/Sender_Policy_Framew
IT'S FIXED!!! (Score:3, Informative)
This problem has been going on for a whole week, and now the very morning that this complaint appears on slashdot is the same morning that the problem is fixed. Coincidence? Or is it that the impending publicity motivated someone to reprioritize this problem and do something about it? It's shameful that Sourceforge allowed a communications failure to persist for so long from what is undoubtedly one of their biggest email sources.
In any case I'm very happy that it seems to be working again. Are other gmail users seeing similar improvements?
gmail rejects too many messages (Score:2, Informative)
In September gmail started rejecting many good e-mails. That's why I've switched to my ISP's e-mail.
I want to receive all incoming e-mails, but in gmail it's impossible to disable filters.
Messages are blocked in the SMTP session, there is no way to whitelist a sender.