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.

Comments

Sourforge?

[eldavojohn]

Worth noting that Sourforge and Slashdot are both part of OSTG.

After all the great software I've found on there, I'd call it sweetforge.

Re:Sourforge?

[Anonymous Coward]

A haiku

Sourceforge is a name
that fails to describe so well
How sweet a forge 'tis

Re:Sourforge?

[Anonymous Coward]

After all the great software I've found on there

Yes, it's so useful to have a choice of 13,237 window managers. Linux just won't be ready for the desktop until we have at least 187,467 window managers, each using its own widget-libraries.

Re:Sourforge?

[ronanbear]

And there was me thinking google were more concerned with sourceforge.

How appropriate...

[Amazing Quantum Man]

Nothing for you to see here. Move along.

Re:How appropriate...

[i kan reed]

1. That joke is tired (and not in the soviet russia, "I'll pretend to laugh and mod funny anyways" kinda way) 2. It's not really all that appropriate here, except that like the article's subject, it's related to a bug. 3. Copy and paste just isn't funny. You may as well say "First post"

Loss of communication can only mean one thing...

[photozz]

Invasion.

Why is the email bouncing?

[Anonymous Coward]

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?

Re:Why is the email bouncing?

[Anonymous Coward]

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.

Re:Why is the email bouncing?

[Anonymous Coward]

That still doesn't explain the problem like some message headers would. All we know is that someone switched on sender verify.

Re:Why is the email bouncing?

[doti]

Here you go, a complete bounced message from sf.net:

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:Why is the email bouncing?

[deepb]

Yes, actually it does explain the problem. The envelope sending address that Sourceforge is using does not exist on their mail server. Gmail is actually checking that during the SMTP conversation and then rejecting the message with a 451 error when it figures out that the address is invalid.

It's OK to say, "I don't know". Asking for more information when you really don't need it is just wasting time.

Re:Why is the email bouncing?

[Anonymous Coward]

I'm not an SMTP wiz or anything, but I think you've got that backwards. It looks like SF that's rejecting the message from Gmail because it can't verify the sender...

Re:Why is the email bouncing?

[Anonymous Coward]

It's OK to say, "I don't know". Asking for more information when you really don't need it is just wasting time.

The message headers posted above illustrate perfectly what's happening, if you'd read them before commenting then you wouldn't have made such a complete dick of yourself. Just because you are eager to jump to the wrong conclusion that doesn't give you the right to chastise those asking for more info.

Re:Why is the email bouncing?

[fluffy99]

==> 451-Could not complete sender verify callout for .
==> From: "Rodolfo Borges"

Isn't the FROM line missing an actual domain name, which would explain the "callout for ___" error?

Re:Why is the email bouncing?

[doti]

The actual address was there in the original email I copied from.
Someone (/.?) has filtered it out. The same happened to the CC: addresses.

Re:Why is the email bouncing?

[deepb]

The message headers posted above illustrate perfectly what's happening, if you'd read them before commenting then you wouldn't have made such a complete dick of yourself. Just because you are eager to jump to the wrong conclusion that doesn't give you the right to chastise those asking for more info.

That's the point - I didn't need to look anything else. Considering I didn't jump the wrong conclusion, I don't think I missed anything by skipping over those headers. I may have typo'd which site was doing the SMTP callbacks, but that was obviously not the focus of my original message.

Hint: Bounces (NDRs) are mostly presented in a standard format. The bounce "message" provides little useful content beyond the reason (error message) why it was bounced. Since that reason was included in the original post you replied to, there's nothing to gain by reviewing the headers of the bounce itself. This problem is obviously domain-specific as opposed to server-specific, so we know where the mail came from, and we know where it's going (two bits of information the Received headers would provide).

Although, if you have no clue what you're talking about, asking for headers can serve as a credible foundation for a future excuse as to why you can't solve the problem. Maybe you could prove me wrong by pointing out which headers you used to track this problem down..?

Re:Why is the email bouncing?

[IthnkImParanoid]

I think anything in angle brackets gets eaten when you're not using plain text mode.

Re:Loss of communication can only mean one thing..

[Anonymous Coward]

I for one welcome our new e-mail bouncing, blame placing, invading overlords!

Re:Not Google's only screwup

[olyar]

Google AsSense and some Blogger content also seem to be having issues...

Probably Sourceforge?

[Chris_Jefferson]

The message linked to in the post says the person is having trouble with both gmail and sending mail from his own domain. I have also had trouble with sourceforge, where mails from my ISP seemed to be "eaten" about half the time. I've just moved mailing lists off sourceforge, although I'm still using them as their svn support is good. Unless anyone else is having trouble with gmail, I'm tempted to just lay all of the blame at sourceforge.

Re:Probably Sourceforge?

[srussell]

Unless anyone else is having trouble with gmail, I'm tempted to just lay all of the blame at sourceforge.

Hear, hear. Considering all of the problems I've (personally) encountered with SourceForge (broken databases, unresponsive, utterly down) and how few problems I've seen with Google (as in, none), I'd be inclined to think the problem is on SourceForge's end. Google has a reputation for reliability and quality. SourceForge, on the other hand...

--- SER

Re:Probably Sourceforge?

[doti]

Yeah, Sourforge sucks.

Not only it's full of flaws, but the interface is awful.
Trac is the way to go.
We need more large-scale sites offering Trac hosting.

The game I'm currently working on, QonkD, is hosted at a site that uses Trac, and I'm very happy with it.
(Note that they accept only projects in the D programming language, and their site is a bit slow, probably cause it's small and lack resources.)

Re:Probably Sourceforge?

[HiThere]

I've never managed a project. As a USER of projects, I prefer the Sourceforge interface.

OTOH, Trac is usable. I don't know how it scales.

Re:Probably Sourceforge?

[harmonica]

Google's AdSense service has problems on a regular basis. Some of the smaller new beta projects have even more. "Google reliability" depends on the exact service. Web search runs smoothly, but I've also encountered outages there.

Re:Probably Sourceforge?

[Bieeanda]

I can't stand Sourceforge as a user. Using Firefox on Windows to try and sign up for an account, so that I can have some neckbeard tell me that it's my fault that popfile is choking on specific keywords, results in literally nothing. No error message, no confirmation message, nothing but another blank account request form. I eventually had to sign up using IE, which struck me as being terribly ironic.

Re:Probably Sourceforge?

[Micah]

We just started having gmail bounce mail from us either today or yesterday.

----- The following addresses had permanent fatal errors -----
<yoderm@gmail.com>
    (reason: 550-5.7.1 Our system has detected an unusual amount of unsolicited)
 
  ----- Transcript of session follows -----
... while talking to gmail-smtp-in.l.google.com.:
>>> DATA
<<< 550-5.7.1 Our system has detected an unusual amount of unsolicited
<<< 550-5.7.1 mail originating from your IP address. To protect our
<<< 550-5.7.1 users from spam, mail sent from your IP address has been
<<< 550-5.7.1 rejected. Please visit
<<< 550-5.7.1 http://www.google.com/mail/help/bulk_mail.html to review
<<< 550 5.7.1 our Bulk Email Senders Guidelines. 1si830441qbh
554 5.0.0 Service unavailable

Which is bullcrap. I just grepped the mail logs; we've sent less than 200 messages to them in the last 5 weeks, and other computers are firewalled off from port 25 outbound. They have to go through the mail server.

Re:Probably Sourceforge?

[reanjr]

Perhaps you've been compromised and don't know it. Or may 185 of the 200 messages you sent were marked as SPAM by GMail users.

Re:Probably Sourceforge?

[Micah]

Well I just realized I was mistaken about the firewall. Some 'Doze computers did indeed have direct access out 25. I just fixed that.

Re:Probably Sourceforge?

[srussell]

As a USER of projects, I prefer the Sourceforge interface.

Do you? Do you really? Do you actually like clicking through five pages of ads to get to a download? You like the broken mirror links? You like CVS?

You, sir, are a bona fide masochist.

--- SER

Re:Loss of communication can only mean one thing..

[Archangel Michael]

I wish I had mod points.

Re:Not Google's only screwup

[arnott]

are u talking about this page : http://www.google.com/services/ ? it works for me. have u disabled javascript ?

Umm

[nizo]

Fortunately, Sourceforge blames Google and Google is blaming SourceForge for this.

I don't think that word means what you think it means. Unless you are glad that no one is willing to take responsibility for the problem and fix it???

Re:Umm

[Rob T Firefly]

Fortunately, the word Schadenfreude does mean what I think it means.

Re:Umm

[Anonymous Coward]

Hello, I'm sarcasm, I don't believe we've met before.

Re:Umm

[Ravensfire]

I think you need to turn on your Sarcasm Detector (TM)(Patent Pending).

-- Ravensfire

Re:Umm

[scsa]

Must have intended "Typically" or "Redundantly" or "In yet another blow to our online freedoms" or "Thanks to the RIAA" or "Due to monopolostic business practices by Microsoft" or ...

Re:Umm

[Anonymous Coward]

Ever looked up the *real* definition of irony?

Re:Umm

[nizo]

Does this qualify?

Re:Umm

[Billosaur]

Unless you are glad that no one is willing to take responsibility for the problem and fix it???

But of course! People are always taking responsibility for the error of their ways ("I was molested as a child by priests," "I didn't see the iceberg," "They told me they were herbal supplements," etc.). It's nice to see a couple of groups turning over a new leaf and denying that either have anything to do with the problem rather than having this tedious mucking about taking the initiative, issuing mea culpas, and solving the problem.

Note: The above was sarcasm. If you did not know it was sarcasm, consult your physician and they will issue you a prescription for a pill that will make it better.

Re:Umm

[onion2k]

A sarcasm detector? Like that'd be useful.

Re:Umm

[narzy]

I would find such a device highly useful. I am one of many people who find it hard to differentiate sarcasm from strait forward conver...wait a minute...

Re:Umm

[houghi]

A sarcasm detector? Like that'd be useful.

I think it would, because many people don't recognize it when they see it.

Re:Umm

[Captain Hook]

Note: The above was sarcasm. If you did not know it was sarcasm, consult your physician and they will issue you a prescription for a pill that will make it better.

Note: the previous note was also sarcasm, do not consult your physician.

Re:Umm

[GKThursday]

How do you stop it from getting overloaded after .5 seconds on /.? I tried the beta version, but it never worked for that reason. Did they fix the compatibility issue in the final release? ~Thursday

Re:Umm

[Anonymous Coward]

I think it would, because many people don't recognize it when they see it. ...as you just demonstrated.

(P.S. that was an approximate quote of Comic Book Guy from The Simpsons)

Re:Umm

[Anonymous Coward]

Hello, I'm sarcasm, I don't believe we've met before.

Hello, I'm a lame joke. I spend a lot of time at Slashdot.

Re:Umm

[Anonymous Coward]

"inconceivable!"

Re:Umm

[Lurker187]

But this is /., so what we really need is a device that detects a LACK of sarcasm. After all, you don't want to spend your whole gadget budget on batteries, do you?

Re:Umm

[Spurion]

Technically that would be irony. Sarcasm (from the Greek for "tearing flesh") has offensive intent by definition.

Re:Umm

[Anonymous Coward]

Hello, I'm irony. I'm the guy who is often mistaken for sarcasm.

Re:Umm

[DCstewieG]

You seem to hang out here a lot. Maybe you should register.

Re:Umm

[That's Unpossible!]

Yeah right...

Re:Umm

[Anonymous Coward]

We know.

Re:Umm

[Anonymous Coward]

as you just demonstrated..

Wait... there has to be some catch here.

Re:Umm

[Joe Snipe]

Possibly the funniest thing I have read all week. It's like some bitter form of art imitating life. I'm picturing a new generation of "hip" legalese rife with sarcasm and self-deprication. Hmmm...

and I'm back to depressed...

Re:Umm

[maxwell demon]

If people don't recognice a sarcasm detector when they see it, then how can it be useful?

Re:Umm

[maxwell demon]

If it were not the case, the problem probably would be long fixed, and thus he would not have had the opportunity to get this story on slashdot, earning him some good Karma. Thus it's fortunate for him.

Re:Umm

[Anonymous Coward]

Yeah, well, they don't sell those in police-states, such as yours. ;-)

SourceForge is good for spewing into the ether...

[jazzkat]

I've had cases where mail coming from SourceForge never reached me; their servers never even attempted to connect to my e-mail server (i.e. nothing in the logs to indicate this). I was running my own DNS at the time, at a colocation center, and never had problems sending or receiving e-mail before with any other domains.

Seemed like sarcasm

[BeeBeard]

I understood it as sarcasm, code for something like "isn't it almost always the case that companies refuse to be accountable for screwups?" That one word could be shorthand for all of that is what's so great about language. ;)

I don't see the problem...

[Anonymous Coward]

...you all have the source code, and the developers do not consider this a priority, so feel free to solve your problem and post a patch

Re:I don't see the problem...

[muszek]

ditto, it's not a bug, it's a feature!

Re:I don't see the problem...

[Anonymous Coward]

I don't see what the problem is...it was fixed in CVS months ago. Not our fault your distro won't update. Is it too much to ask for you to download the latest source and recompile? Damn lunix n00bs.

well this looks clear as mud

[LiquidCoooled]

Greetings,

This is something recent that has changed in how Google handles
email (other sites have started to get the same errors). We
are investigating how to deal with this.

SourceForge.net Support

Is it because sourceforge is not following the RFCs and google has just tightened up?

We had a similar issue in one of our programs where mailing worked wonderfully for months and months for all customers, then one morning complaints started.
It appears as though we weren't following the RFCs to the letter and the main isp in our country (bt) had updated to a more stringent mail server (we shockingly used an additional CR where one was not expected...).

This all sounds similar.

Re:well this looks clear as mud

[jfinke]

Been there as well. Our developers were using a old library that was compliant to the old SMTP RFC, but not that new one. When we switched firewalls from proxy (which was rewriting the smtp packets under the new RFC) to statefull inspection 5% of our clients has munged up attachments. It was really odd.

Re:well this looks clear as mud

[Anonymous Coward]

(we shockingly used an additional CR where one was not expected...)

So..... Basically, you did not adhere to the RFC and are now bitching that things don't work.

Perhaps all RFC's shoudl work like this, I mean shit, I can make a whole busienss model out of programminn things that, while not 'technically' correct, seem to work.

Re:well this looks clear as mud

[Anonymous Coward]

Perhaps all RFC's shoudl work like this, I mean shit, I can make a whole busienss model out of programminn things that, while not 'technically' correct, seem to work.

Leave Internet Explorer out of this...

Re:well this looks clear as mud

[EvilGrin666]

Perhaps all RFC's shoudl work like this, I mean shit, I can make a whole busienss model out of programminn things that, while not 'technically' correct, seem to work.

Sounds like Microsofts business model. :)

Re:well this looks clear as mud

[LiquidCoooled]

Yes, it was a coding mistake.
It appeared to work in all test cases we came across.

Re:Why not just dump GMail?

[dk.r*nger]

Why not just dump SourceForge? Surely there are utilities to migrate to another development platform or an open source repository solution...

SourceForge value = GMail value

[xxxJonBoyxxx]

Mostly because web mail packages/services like Gmail are a dime a dozen; SourceForge provides more unique value to the average techie.

Re:SourceForge value = GMail value

[thrillseeker]

because web mail packages/services like Gmail are a dime a dozen; SourceForge provides more unique value

Thank you for choosing the better answer for everyone.

Re:SourceForge value = GMail value

[muszek]

Even if this whole mess was G's fault (I don't say it's not), it's migrate one (or x) mailing list from sourceforge to something else than to persuade n (or x*n) mailing list's (or lists' :) ) users to migrate from gmail to something else.

Re:SourceForge value = GMail value

[Anonymous Coward]

Your usage of "more unique" is not strictly correct. "Unique" does not have a magnitude associated with it, it is a binary condition. Something is either unique, or it is not. Now you know.

Re:SourceForge value = GMail value

[Anonymous Coward]

SF sucks. We selected SF to host one of our company's GPL'd projects without researching the alternatives, and it's been one screw up after another on SF's part. Support is non-existant.

Belios seems to be a feature-for-feature clone, but they're smaller and more responsive. There are many similar services, Berlios as least has a good track record behind it. Google code seems a bit underfeatured. In the end we just installed Trac and self-hosted. Way better.

Re:SourceForge value = GMail value

[l0cust]

SourceForge value = GMail value

Mostly because web mail packages/services like Gmail are a dime a dozen; SourceForge provides more unique value to the average techie

next time I get an infinite loop.. I am sueing your ass!

Re:Why not just dump GMail?

[Anonymous Coward]

And dump the next two ISPs and addresses that also have trouble with Sourceforge.net mailing lists. Like I did back before GMail existed. Maybe if Sourceforge became an ISP, we wouldn't have these problems.

eh

[erikdotla]

Troubleshooting IT on message boards involving the public is a highly effective way to get things done.

Allow me to start. *ahem*

WHY is SourceForge even using SMTP????!!!

Re:eh

[einhverfr]

Because X.400 isn't as widely accepted yet ;-)

What we REALLY need is a full OSI protocol stack build on top of TCP/IP so we can use all the wonderful features of X.400, X.500 (instead of messy LDAP), and so forth!

Re:eh

[idontgno]

Because X.400 isn't at all accepted, anywhere, and never was ;-)

There, corrected that typo for you.

Re:eh

[einhverfr]

Actually it was accepted briefly in some areas (which is why Exchange 5.5 included an X.400 connector). Most notably in the military.

Of course that is different from the point of my post which is largely that the alternatives to SMTP are overengineered monsters like X.400....

Re:eh

[saddlark]

Exchange was ported to the world of SMTP. Initially, it used X.400, which it still does internally (IIRC!).

Re:eh

[3247]

Of course that is different from the point of my post which is largely that the alternatives to SMTP are overengineered monsters like X.400....

UUCP?

Open Source vs. Google

[patio11]

Who is the Slashdotter to root for? Hmm... I know, third option! It is Microsoft's fault!

Re:Loss of communication can only mean one thing..

[garcia]

They don't have a "+1 Nerd Movie Quotes" mod, sorry. :)

Google's Answer if they find it is them...

[tecker]

Original Response:

Google's response to this bouncing has been automated e-mails saying it is probably at the other end of mail delivery.

New Response:
"Well Gmail is still in beta so don't blame us."

Re:Google's Answer if they find it is them...

[chromatic]

Perhaps all of the GMail developers transferred off of the team?

Don't be evil...

[tygerstripes]

...but nobody said anything about complacency!

Glad I'm not the only one losing messages

[JewGold]

In the past couple weeks I've "lost" at least a dozen messages on gmail. Not bounced, not in spam filter, they just don't appear.

Re:Glad I'm not the only one losing messages

[Anonymous Coward]

Stop clicking delete should help find them in the future.

Re:Glad I'm not the only one losing messages

[corvair2k1]

I feel ya. I've had enough dropped emails, both to and from gmail, that I don't use it for anything more than my pizza order confirmation anymore.

I desperately wanted to use it for my main email, but I ended up finding a bug where responding to a message in the middle of the conversation would just not deliver the message at all. Unfortunately, it was quite an important message... so that pretty much turned me off from gmail forever.

It's your fault

[PinkyDead]

No, it's your fault
No, it's your fault
No, it's your fault
No, it's your fault
No, it's your fault
No, it's your fault ...

How do they know it's broken?

Re:It's your fault

[Anonymous Coward]

Greetings,

      Very easy. They are sending EMAIL to each other. ;)

      It's kind of like emailing the IT dept to tell them that their email servers are down. ;)

E-mail isn't reliable, ya know

[Toe, The]

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.

Re:E-mail isn't reliable, ya know

[A coward on a mouse]

Sure, email is not 100% reliable. Got it. It sounds as though this particular link is nearly 0% reliable. If the mail room at your credit card company loses one payment, that's not cause for a complaint. If they lose nearly every payment sent from a given state, you can bet that would be cause for a complaint.

Re:E-mail isn't reliable, ya know

[Toe, The]

The thing about computers is that they can do the wrong thing much faster and much more reliably than humans.

Re:E-mail isn't reliable, ya know

[Midnight Thunder]

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.

Maybe not, but everything works better if there is at least some attempt to warn the sender that something screwed up. For this reason even if Google did change their mail system to be more compliant, they should recognise non-compliant e-mail and either handle it or send an explanation on why they are refusing it. If you look at web browsers and HTML, then there is definetly a specification indicating what well structured HTML should be, but they still do a best job when they get pages that aren't. I think for e-mail it should be the same.

Re:E-mail isn't reliable, ya know

[walt-sjc]

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.

No, the RFC's aren't written in stone, but they DO exist, and they exist for a reason. No email software HAS to adhear to the written standards, but when they don't, your chance of having problems grows dramatically.

Many of the anti-spam systems out there deliberatly violate the standards in order to be more effective. Sometimes the violation is minor and everything still works well. Other times the anti-spam solutions are so poorly designed that they have constant problems with a high rate of legitimate mail lost (verizon is a great example of this.) This is why I pay more for a static IP and run my own home email server for family and friends (which I've done for about 10 years now.) If I have a problem, I: 1) know about it, 2) can fix it NOW.

SPF records....

[leto]

Google has SPF records. Sourceforge seems to reject mail that seems spoofed (eg people 'pretending' to be allowed to send user@gmail.com mail without going through google.

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:SPF records....

[Hijacked Public]

You get what you pay for

Clever.

Re:SPF records....

[tokul]

Google has SPF records. Sourceforge seems to reject mail that seems spoofed

Sourceforge has SPF records too. Don't know if gmail.com uses SPF filtering.

Re:SPF records....

[nuzak]

> Google has SPF records. Sourceforge seems to reject mail that seems spoofed (eg people 'pretending' to be allowed to send user@gmail.com mail without going through google.

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.html for an explanation.

Just one more reason to jump ship from sourceforget.

Re:SPF records....

[SiliconEntity]

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.

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.

Re:SPF records....

[Anonymous Coward]

Gmail.com SPF record is:

_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_Framewo rk

Re:SPF records....

[mpe]

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.

Conceptually it isn't "broken". Though a specific implimentation may well be broken. Handling MX lookups appears to be something a common problem with MTA implimentations, e.g. aplication caching of DNS.
Even if the implimentation is absolutly spot on there is the issue of interaction with "anti-spam" systems, especially those which use black or white lists.

Re:SPF records....

[nuzak]

It's not the MX lookup that's the broken piece, it's the connecting to the MX (thus believing the From: line in the first place) and attempting to send a bogus piece of mail as an expensive and verbose end-run around VRFY that's broken. It's astonishingly broken when things are deliberately sent from "do-not-reply" addresses.

Re:Loss of communication can only mean one thing..

[Rogerborg]

Harlan Ellison's best work!

Seems pretty clear here

[xxxJonBoyxxx]

When my email client and/or ISP starts to piss me off, I swap it out with something better. It may take a few hours to do so, but after that I'm enjoying better features/performance/whatever I was after. If Gmail is starting to suck, dump it - right? (Don't tell me you've already suffered "vendor lock in" with Google; you're a Slashdotter, after all.)

I'm not sure how long it would take to swap out of SourceForge, but I'd bet it would be more than a few hours. (Thus the call for "utilities"...)

Google offers Sourceforge-like services

[einhverfr]

I am considering dropping Sourceforge for Google partly for this reason. I have had trouble with some of my other domains and Sourceforge isn't even interested in helping me get my email servers working properly with their system.

Re:Google offers Sourceforge-like services

[AJWM]

And now you know why Google is bouncing Sourceforge email.

Or vice versa.

I beg to differ

[geoffspear]

"All e-mail going back and forth from Sourceforge and Gmail" is certainly not being bounced. My Gmail account has been getting plenty of email from Sourceforge during the period when "all e-mail" has supposedly been bouncing.

Of course, this is the sort of accuracy I expect from Slashdot.

Re:I beg to differ

[narzy]

Hey, if you want accuracy go to a shooting range for the blind!

SourceForge uses Mailman

[ben there...]

In my opinion, the problem with SourceForge lies in that Mailman doesn't work well with Gmail addresses. I use Mailman discussion lists on my DreamHost account, and while testing I couldn't get the emails to work until I added a non-gmail account. I contacted support, blaming them for a while and getting frustrated, until I tried a different email account.

This was DreamHost's response:

I've closed out this ticket for you. I thought I should mention however
that quite a few people that have forwards to gmail have ran into similar
problem, the only thing that is consistent is that the messages make it
to the gmail relays and then disappear.

I don't know if that means that GMail rejects Mailman messages, or Mailman has problems sending to Gmail addresses, but one way or another, it doesn't work right.
--
Use coupon DH75OFF to get $75 off hosting at DreamHost.com

Re:SourceForge uses Mailman

[HiThere]

Well, one thing it means is that I'm glad I don't use GMail.

And it appears to mean that you shouldn't use GMail if you want to talk to SourceForge.

Presumably things will eventually be fixed, but for now that looks like the proper "answer".

Re:SourceForge uses Mailman

[Anonymous Coward]

That's not true, at least not for Mailman in general. We have tons of gmail addresses on our Mailman mailing lists at python.org and we have no problems that I'm aware of in delivering to those gmail accounts.

Re:SourceForge uses Mailman

[Roliverio]

Having used Mailman plenty of times for large periods, we have a couple of rather large mailman lists, presently, there are two of them wich i administer whose e-mail addresses consists nearly of 90% gmail users, without a single glitch or problem, it's not a mailman fault, it could be a sf.net issue with their mail servers, or a google issue, but it's definetly not a mailman issue.

Re:SourceForge uses Mailman

[ben there...]

True, it could just be a coincidence. Or it could be a particular (default?) setting in Mailman that causes/prevents getting bounced by gmail that some administrators get right, while others don't.

I don't know what the specific problem may be. I just know that 2 large hosting services both use Mailman and both get bounced by gmail.

Re:SourceForge uses Mailman

[gkhan1]

I'm subscribed to a few of wikipedias mailing lists that use mailman. I get a few hundred messages a day from them total, and Gmail has never complained, and I never had any trouble with it. I highly doubt there is anything wrong with how google handles it, especially since obviously the sourceforge mailinglists worked before. Something happened a week ago, and that's what people need to look into, not throwing bad code accusations to any software involved.

Re:SourceForge uses Mailman

[oddiofile]

That's not an option! With my project (jedit) half of my developers are all using gmail. What's a good alternative?

Anyway, according to gmail, the problem is resolved, but according to sf.net it is not. I am still not getting any messages delivered to sf.net mailing lists.

Re:SourceForge uses Mailman

[HiThere]

Sorry, I didn't mean that it was an option for you. I meant that not using GMail meant that it has appeared to be still working to me.

I can easily believe that the problem is created by SourceForge, and that for a project maintainer it could be quite difficult.

Can you expand on this a bit?

[xxxJonBoyxxx]

Can you expand on this a bit? (i.e., What Sourceforge-like services are available?)

Re:Can you expand on this a bit?

[einhverfr]

http://code.google.com/hosting/

Includes web space, svn hosting, a tracker, and the like.

Re:Why not just dump GMail?

[Paco103]

Sure, there are great utilities for this task. But they're all on sourceforge!

Callbacks Are Evil

[ccandreva]

I would say this is Gmail's problem.

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.

Re:Callbacks Are Evil

[140Mandak262Jamuna]

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.

Re:Callbacks Are Evil

[joekampf]

So the email server that sent the email is required to ensure that it actually not spam. And this is evil? I get almost no spam in my Gmail account. I love it. LOVE IT, LOVE IT, LOVE IT! I get atleast 30 emails a day of spam to my company's email account. Hate it, hate it, hate it.

Re:Callbacks Are Evil

[Anonymous Coward]

actually sourceforge is verifying senders also

Re:Callbacks Are Evil

[ccandreva]

> So the email server that sent the email is required to ensure that it actually not spam

No. The e-mail server that handles whatever domain happens to be in the sender field is being asked if the address actually exists. There is a big difference.

People can put whatever address they want in the From: field of their mail. Return addresses are forged in spam all the time.

It is becomming a very big problem, when someone decides to forge your return address into 100,000 pieces of spam, and now your server has to deal with all those connections back. Not to mention the Outlook "Iam out of the office messages", or bounces from idiot servers that accept mail for any address THEN boune recipients that don't exist.

It's dumping your garbage on my lawn. It's evil, and it's just as wrong for Sourceforge to do them.

Re:Callbacks Are Evil

[idontgno]

Initially callbacks will be evil as you say.

Agreed.

...starts tagging which ip addresses in the call chain are routinely sending spam

Because spammers are tards and never never NEVER change which bots they use for their spam runs. And the bots are all on static IP addresses so prevalent in the dial-up and consumer broadband arena. So, learn IP address once, good forever.

So give them some slack please.

When they stop violating the inter-MTA interchange dictated by standards. Until then... well, at least you got the "evil" part right.

Re:Callbacks Are Evil

[cyngus]

No, this is not always the case. Spammers tend to forge the "from" address. So the message is actually sent from billys-compromised-computer.dsl.att.net with the form field is "george@example.com". In this case GMail attemps to send a message to "george@example.com". If the message doesn't bounce, hooray, maybe this isn't spam. So this actually takes the resources of example.com not billys-compromised-computer.dsl.att.net. Now, if everyone is doing this, everyone is using up additional resources for verification to solve a spam problem we all have, so it kind of evens out. What might be a good idea is a sort of email reverse dns lookup. So you can lookup the IP of the sending server and see if its registered to the domain that the message appears to be from. This probably opens up a world of other problems that I don't have time to consider though.

Re:Callbacks Are Evil

[ccandreva]

> This probably opens up a world of other problems that I don't have time to consider though.

Such as, if you are example.com, what happens when Joe Spammer uses his 1,000 node botnet to send 1 million spams with your domain forged, and 1 million hosts try to do the sender-verify at the same time.

It doesn't scale.

Re:Callbacks Are Evil

[Mark J Tilford]

If gmail is rejecting the message because the callback failed so they think it's spam, why don't they at least put it in the spam folder?

(Or, how do I get to the "Show all messages regardless of what you think; I'll decide whether it's spam or not" option?)

Re:Callbacks Are Evil

[cmdrbuzz]

Our implementation checks the SPF records before making a VerifyMailFrom check.

And we cache the responses to help with the load.

Re:Callbacks Are Evil

[Schraegstrichpunkt]

Your standards are obsolete.

Re:Callbacks Are Evil

[cyngus]

You missed my point a bit. Spam is a problem of the internet community in general. If we're all using the same tactic to try to thwart it no one is bearing an inordinate amount of the burden of solving the problem. This doesn't address your problem, but it wasn't meant to.

Re:Callbacks Are Evil

[nuzak]

> Gmail is initiating what are called call-backs.

From my read of the bounce, it looks like sourceforge is the one doing the callbacks. Am I wrong here?

http://it.slashdot.org/comments.pl?sid=199035&cid= 16307185

Re:Callbacks Are Evil

[makomk]

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.

Out of curiosity, how does this interact with greylisting? (Or indeed, what happens when the receiving SMTP server is down or overloaded?)

It doesn't really seem like a good idea, especially as IIRC some SMTP servers are set up to never reject mail immediately for any request (even if the name isn't known) in order to stop spammers from using this technique to discover valid e-mail addresses, so spammers can just fake it as coning from those. (Or use the same verification technique against their own lists to find a load of valid e-mail addresses, and then use them as the From addresses - plus, then they have some good candidates for spam...)

Re:Callbacks Are Evil

[The MAZZTer]

Parent is correct. I can use PHP to programmatically spoof a From address easily... of course, I can't spoof the origin SMTP server (at least not as easily), but it's still enough to fool your average Joe.

It's the different between send("to@email.com", "Subject", "Body"); and send("to@email.com", "Subject", "Body", "From: Someguy ");. That's all it takes.

Re:Callbacks Are Evil

[jonfelder]

What might be a good idea is a sort of email reverse dns lookup. So you can lookup the IP of the sending server and see if its registered to the domain that the message appears to be from. This probably opens up a world of other problems that I don't have time to consider though.

Congradulations, you've invented SPF: http://en.wikipedia.org/wiki/Sender_Policy_Framewo rk

Unfortunately, while somewhat effective, SPF breaks mail forwarding.

Re:Callbacks Are Evil

[idontgno]

Now I know who to go to have nits picked. If I ever have that problem.

But more significantly, the point stands.

Re:Callbacks Are Evil

[140Mandak262Jamuna]

It is true that there are vast botnets. And the spammers routinely change the bots. And most bots are on dynamic ip address that keeps changing. You are right in saying that I or you or most other companies would not have the resources to combat spam by tagging the ip addresses. But if there is a company that has the resources, both in terms of money and in terms of searching, organizing and finding patterns it would be Google.

Most legitimate mailservers are running on static ip addresses. Google will be able to compile a list of legitimate good mailservers rather quickly. Google is also an IP address registrar. It has the routing tables and other registration information and netblock ownership information. It will know the dynamic ip addresses by the block. Mailservers running on dynamic addresses, or relays running dynamic addresses are suspect immediately. It is not proof. But more like preponderance of evidence (IANAL).

Can they determine spam without callbacks in three months. No way. Can they reduce the number of callbacks to confirm legitimacy of email by atleast an order of magnitude? Yes, they can by collecting relay ip addresses, mail server ip addresses, netblock ownership data and putting them all together like "page-rank", "mailserver-rank". They might even find the bots and inform the ISP that they probably have a bot and the ISPs might even contact the boob with the infected machine. Good things can come out of this.

Will they? There you got me. Dont know if they will. But I hope they do.

Re:Callbacks Are Evil

[mpe]

Out of curiosity, how does this interact with greylisting? (Or indeed, what happens when the receiving SMTP server is down or overloaded?)
The correct behaviour would be for the "callback MTA" to return a 4xx code if it cannot establish an SMTP connection to any of the MX hosts or if it receives a 4xx code. Though this dosn't mean that the system in question will do that. Especially if what has been produced is in effect a private hack without careful checking having been made against any possible way another MTA can react within the scope of RFC 2881. (It's also possible that a bug in an MTA's handling of SMTP may only show up when it attempts to perform such a "verification".)

Re:Callbacks Are Evil

[mpe]

Spammers tend to forge the "from" address. So the message is actually sent from billys-compromised-computer.dsl.att.net with the form field is "george@example.com". In this case GMail attemps to send a message to "george@example.com". If the message doesn't bounce, hooray, maybe this isn't spam. So this actually takes the resources of example.com not billys-compromised-computer.dsl.att.net. Now, if everyone is doing this, everyone is using up additional resources for verification to solve a spam problem we all have, so it kind of evens out.

About the only useful bit is that billys-compromised-computer.dsl.att.net. might be kept waiting whilst gmail.com is querying the MX's for example.com to find out if any of them have heard of george.
There are easier ways for gmail.com to make it harder for billys-compromised-computer.dsl.att.net. including methods which are less resource intensive for both gmail.com and example.com.

Re:Callbacks Are Evil

[mpe]

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.

Or to create a DDOS, with an additional level of "protection".
There dosn't appear to have been that much discussion of the idea of "call-backs" prior to implimentation.

Re:Callbacks Are Evil

[Schraegstrichpunkt]

Ok, I'm not advocating "callbacks" here, but do they actually violate the standard? If so, what part?

Re:Callbacks Are Evil

[JKConsult]

Most legitimate mailservers are running on static ip addresses.

With admittedly outdated experience (the last time I touched an MX record was 2000), I'm still willing to say this: If you're running a mailserver on a dynamic IP, you should *expect* to have your mail bounced. I didn't do it then, for a small (in size, medium in revenues) business, why would you do it now, given the hyper-explosion of spam within the last six years?

pragmatism

[Speare]

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.

It is not just a problem with gmail

[ubuwalker31]

I had a heck of a time trying to set up an account at sourceforge using gmail, hotmail, and yahoo, and even my ISP email address. The emails just never got to me. After weeks of trying, I finally got an email confirming my sourceforge account. I don't know the technical nature of the problem, but the email system at sourceforge has got to be improved! Especially since the whole idea behind the site is collaboration! How can you collaborate without email in this modern age!

Re:It is not just a problem with gmail

[Anonymous Coward]

How can you collaborate with email in this modern age (of spam, viruses, and Outlook)?

Re:It is not just a problem with gmail

[mrchaotica]

How can you collaborate without email in this modern age!

Stop ironing your question marks. They're supposed to look wrinkled like that!

I'll dump Sourceforge first

[wsanders]

But, then I don't reflexively hate large corporations.

Gmail doesn't drop any of my other, numerous, mailing lists or subscriptions, and it's spam filtering is 100.00000% percent accurate.

I suspect there are self-righteous Net Nazis on both sides. Hang your frgaile punk ego at the door and fix it.

From the link ...

[khasim]

TEMP_FAILURE: SMTP Error (state 9):
451-Could not complete sender verify callout
451-Could not complete sender verify callout for .

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".

Re:From the link ...

[Intron]

Other way round. SF sends the mail to Gmail with a From address that isn't in the SF domain. Before accepting it, Gmail does a sender verify by starting a mail command to SF with the address in the From. SF says it doesn't accept mail for that user. Gmail then refuses the first mail.

Nothing in an RFC says that a mail sender has to also accept mail with that same address. SF does correctly accept bounce messages, which are addressed to "<>"

You have never had experience with this problem...

[einhverfr]

On my latest open source project (LedgerSMB), several of us including both project admins have been unable to send email to the lists from Gmail accounts because of this issue. Our mailing lists have thus been basically down because of this.

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 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:Loss of communication can only mean one thing..

[roger6106]

Since all email is being bounced does this mean that it is an endless snowball effect with more and more emails being bounced back and forth?

Who will have the last server standing? Google or Sourceforge?

Heretic!

[adavies42]

Genesis 1:32 And God typed :wq!

All true believers know he typed C-x C-s C-x C-c!

Re:Heretic!

[Anonymous Coward]

...now I understand why they say EMACS stands for Escape-Meta-Alt-Ctrl-Shift...

Re:Why not just dump GMail?

[generic-man]

True. GMail's still in beta after 2+ years; it could crash tomorrow and half the Slashdot comments would be apologizing sarcastically for the loss of a free beta service.

The Solution

[Cytlid]

Um, INCOASFML (I'm not currently on a source forge mailing list) but the way I've been operating for years would probably remedy this situation. I have my own domain... I run my own sendmail (insert MTA flamewar here, perhaps someday I'll switch to postfix or qmail or something). I have my own webmail, but it sucks. I signed up for gmail with an obscure username. Gave *noone* the account name. I just forwarded my user on my colocated machine to GMail, and have GMail use that username as a reply to address. Works great. GMail's become my glorified webmail client (it beats the crap outta my other ones).

  So at the end of the day, have your friendly local neighborhood mail admin forward a real domain account to your gmail. Then just change it on sourceforge's list. Then I'm not subject to gmails (or sourceforges) mail policies, only my own.

Re:The Solution

[dschuetz]

I have my own webmail, but it sucks.

Have you tried RoundCube? It's not perfect, but it's better than (for example) SquirrelMail, and has a reasonably active development group. It's about the best I've found, at least among those that are truly web-based (as opposed to downloading a "lightweight" flash client).

Re:The Solution

[Anonymous Coward]

Yes, but what if you want to SEND email to a list on sourceforge ? I believe that's the issue here.

Re:The Solution

[BigAssRat]

IRHIWPCAFTTWOUO

(I really hate it when people create acronyms for things that will only use once)

Re:The Solution

[Cytlid]

Yup, I've tried RoundCube. It looked nice but it had issues. As far as *sending* email goes, you send out your MTA that your forwarding from.

  I guess my point is people who whine about email should run their own email server.

It is definitely Sourceforge's problem

[kindbud]

Sourceforge is posting the following message to bug reports about this problem.

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

[kindbud]

Oops, some angle brackets got munched by the parser because I forgot to HTML-ise them.


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

[pe1chl]

Callback verify is not covered by any RFC

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:It is definitely Sourceforge's problem

[davecb]

They are probably doing a VRFY <person@place> on another connection, which is part of the RFCs, but which is often turned off by MTAs.

Back in the dusty beginnings of time when I was working on mail, the same MTAs that turned off VRFY always said they'd accept RCPT To:<person@place>, so as to be able to avoid any microsecond-consuming checking (;-))

--dave

Re:It is definitely Sourceforge's problem

[cmdrbuzz]

Probably not using VRFY, more likely HELO, MAIL FROM:<>, RCPT TO: , QUIT.

We use the response to the RCPT TO: as verification if the email address is valid.
As no data is sent, the receiving server should abandon the message.

Re:It is definitely Sourceforge's problem

[Greg Couch]

I filed a bug about this with sourceforge years ago. I just wasn't big enough to get them to fix it. The bug has do to the MAIL FROM and RCPT TO protocol. If you use MAIL FROM: , then the RCPT TO: address is supposed to be a bounce address, ie., one that you received. My setup signs all of its MAIL FROM addresses (with SRS), so I can detect bogus bounces. Likewise, if you use a normal, non-bounce RCPT TO address then the MAIL FROM address must be a real address on the sending site (so it passes SPF checks). Pretty simple for sourceforge to fix. Since I'm a small fry, I had to fix it on my end by delaying the verification until the DATA command was received -- not hard, but not as simple. MAIL FROM address verification is a good technique to only accept email you can probably bounce to if there is an error, but it's not needed if the sending site support SPF (if a bounce fails, just blacklist the sending site because it's giving out bogus information).

Re:It is definitely Sourceforge's problem

[Anonymous Coward]

I imagine that Google might have a problem with spammers using mechanisms like this to verify that email addresses at gmail.com actually exist. Or, worse yet, they could use a dictionary-based mechanism to harvest gmail addresses. Most people don't realize it because most MTAs abandon the message, but this kind of thing happens a lot.

One email provider I used to use had a custom MTA that would deliver create a blank message whenever an aborted request happened. Most of the time, they were requests from a valid SMTP server, but there were a bunch of times that I got them where I was able to trace the IP of the requestor back to some cable or dsl connection.

Re:It is definitely Sourceforge's problem

[pe1chl]

Ok with this info I also tried the above.

Result: sourceforge calls back to the server handling the mail from: address.
It does the following:
MAIL FROM:<>
RCPT TO:<source@domain>
MAIL FROM:<>
RCPT TO:<postmaster@domain>

My server replies 250 OK on both of these tests, and as a result the Sourceforge mail server accepts my mail.

Apparently, this is not true for Gmail. I would say it is Gmail's fault. MAIL FROM:<> MUST be accepted, and the postmaster account MUST exist.

Re:It is definitely Sourceforge's problem

[einhverfr]

Maybe google is calling back to make sure that TO: really exists :-)

Re:It is definitely Sourceforge's problem

[einhverfr]

Sorry, that is TO:<>

Ate my angular brackets.

Re:It is definitely Sourceforge's problem

[kindbud]

They are probably doing a VRFY on another connection, which is part of the RFCs, but which is often turned off by MTAs.

Callbacks actually do MAIL FROM:, RCPT TO:, and then RSET the connection before the DATA segment. Relying on VRFY, as you said, would ensure many failed checks and bounced emails.

What annoys me about callbacks is the extraneous log entries it generates on my mail server, which makes it more difficult to interpret log entries for troubleshooting. You have to weed out the callbacks, since they often resemble incomplete or failed transactions.

Re:It is definitely Sourceforge's problem

[kindbud]

Apparently, this is not true for Gmail.

No, they accept mails addressed to postmaster@gmail.com, even from the null sender.


Trying 64.233.163.27...
Connected to gsmtp163.google.com.
Escape character is '^]'.
220 mx.gmail.com ESMTP 39si3446212nzk
helo foo
250 mx.gmail.com at your service
mail from:<>
250 2.1.0 OK
rcpt to:<ReDaCtEd@gmail.com>
250 2.1.5 OK
rset
250 2.1.0 Flushed 39si3446212nzk
mail from:<>
250 2.1.0 OK
rcpt to:<postmaster@gmail.com>
250 2.1.5 OK
rset
250 2.1.0 Flushed 39si3446212nzk
quit
221 2.0.0 mx.gmail.com closing connection 39si3446212nzk
Connection closed by foreign host.

Re:It is definitely Sourceforge's problem

[kindbud]

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.

Yeah, dude. Sendmail does that too if delay_checks is enabled, which it often is for certain spam checks. Your callback has a problem interoperating with frakking sendmail, not just some obscure spam filter.

Re:It is definitely Sourceforge's problem

[mpe]

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>.

What do you mean by "the sending server"? Just because a machine is making an SMTP connection does not mean that it is under any obligation to accept SMTP connections itself. Even if it does it could quite legitimatly return "relaying denied".
The only sensible way of doing such "call backs" is by first doing an MX lookup on the domain part of the RCPT TO: to work out which machines you should even be trying to contact. You also need to be very careful if you use anything other than MAIL FROM:<>. Using MAIL FROM:<mailer-daemon@Yourdomain> raises issues of avoiding mutual recursion. Using MAIL FROM:<mailer-daemon@anythingotherthanyourdomain> means that it is possible to get a "Who do you think you are trying to fool?"/"I don't like open relays" type response.

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.

What do you mean? (See section 4.3.2 of RFC2821.) The only part of a response which any program should be looking at is the 3 digit number. Any text following that is a comment to try and help humans, an MTA may log it but trying to interpret it would be violation of the SMTP protocol.

Re:It is definitely Sourceforge's problem

[davecb]

And if they were talking to my old system at Ork, they'd be getting a (possibly false) positive on every verification that was syntactically valid. Not A Good Algorithm (;-))

--dave

Re:It is definitely Sourceforge's problem

[pe1chl]

first doing an MX lookup

OF COURSE. Please don't try to nit-pick.

Using MAIL FROM: raises issues of avoiding mutual recursion.

OF COURSE the server does not try to callback when it gets a recursive callback that attempts to verify mailer-daemon.

What do you mean?

I mean things like this:

MAIL FROM:<>
250 Ok
RCPT TO:
550 bad sender address <>

This is what you see in the trace. The callback looks only at the 550 and assumes it refers to the recepient address. But the message indicates that the receiver is actually rejecting the source address. It should have sent the 550 reply on the MAIL FROM command! Because it doesn't, the callback procedure assumes the sender address is invalid. Had the receiver replied with 550 on the MAIL FROM:<> the callback would have tried with mailer-daemon and it would probably have worked.

Re:It is definitely Sourceforge's problem

[pe1chl]

Then either the issue has been fixed, or the behaviour of one of the parties varies depending on who they communicate with.

Re:It is definitely Sourceforge's problem

[pe1chl]

Remember it is only a problem when the receiver is attempting to reject MAIL FROM:<>
That is a violation of the RFC.
And then, it only fails when the check is delayed. The RFC does not really allow that either.
In practice I have never seen this combination happen.

The SMTP server does not interoperate with many nonconformant clients. That is exactly what its purpose is: to refuse to talk with amateurishly written SMTP clients used by spammers and worms. It is very successfull at that.
I have never seen it fail with sendmail. But it should be mentioned that sendmail is used less and less in the (business-to-business) environment this server is operating in.

Gmail and SPAM filtering

[SpentFuel]

Gmail seems to frequently get blocked by spam filtering. As many companies buy their spam filtering from third parties, the really have little control or expertise in it. Some spam filters work on strange rules, e.g. put one too many hyperlinks in a message and your email goes to the bit bucket.

Matter of fact, I've had problems with Slashdot mail messages and spam filters in the past. Just try to get an domain unblocked with your corporate IT undead and see how easy it is!

Re:Loss of communication can only mean one thing..

[bobtheinsanecow]

In Soviet Russia the emails... arrrhhg!a;ughvo89hg804oithj9p0

Re:Loss of communication can only mean one thing..

[X0563511]

no... Yahoo!

Re:Not Google's only screwup

[Anonymous Coward]

You're a moron. Go post on some other site.

Re:Not Google's only screwup

[Software]

My bad. I had google's ad server blocked in my host file. I guess they were serving some JavaScript that the rest of the page needed.

Re:Not Google's only screwup

[Eunuchswear]

Huh? If he's a moron he's in the right place.

You can stick around too.

its most likely sourceforge thats at fault

[Anonymous Coward]

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.

Re:its most likely sourceforge thats at fault

[Anonymous Coward]

Saying SF is some kids in a basement is like saying the Great Lakes are a couple of ponds.

Re:its most likely sourceforge thats at fault

[Anonymous Coward]

Okay, it's some full grown adults in a basement then.

Re:Loss of communication can only mean one thing..

[mennucc1]

(here comes the quote nazi:)
A communications disruption can mean only one thing - invasion. (MP3)

Re:Umm - Oblig. Reply

[just_another_sean]

Lisa: Dad, do you know what Schadenfreude is?

Homer: No, I do not know what shaden-frawde is. [sarcasm] Please tell me, because I'm dying to know.

Lisa: It's a German term for `shameful joy', taking pleasure in the suffering of others.

Homer: Oh, come on Lisa. I'm just glad to see him fall flat on his butt! [getting mad] He's usually all happy and comfortable, and surrounded by loved ones, and it makes me feel... What's the opposite of that shameful joy thing of yours?

Lisa: [nastily] Sour grapes.

Homer: Boy, those Germans have a word for everything!

Google Mail *BETA*

[martin]

Looking at my gmail account it shows a little *BETA* under the Google mail logo.

Call me stupid but using beta grade software for real world stuff could be asking for trouble by the many people using the gmail service....

Re:Google Mail *BETA*

[waferhead]

Martin (1336) said:

"Looking at my gmail account it shows a little *BETA* under the Google mail logo.

Call me stupid but using beta grade software for real world stuff could be asking for trouble by the many people using the gmail service..." ...Never stopped Microsoft.
(Obligatory)

Where did you buy that 4 digit UID? ;-)

Re:Google Mail *BETA*

[martin]

I was lucky enough to be told about /. very early on..

Re:Why not just dump GMail?

[0110011001110101]

welcome to slashdot, you must be new here.

comments "apologizing" for anything do not exist.

If you have any questions about this post, it is in sourceforge, simply email me at youmustbenewhere@gmail.com.

Not much of a surprise.

[arose]

Sourceforge has been blocking my email for ages, from the biggest ISP of the country no less. This of course is on a whole different level (small country :-), but doesn't surprise me.

Re:Not much of a surprise.

[smitty97]

Sourceforge has been blocking my email for ages, from the biggest ISP of the country no less.

Do you really want email from an AOLer?

Re:Not much of a surprise.

[arose]

What part of "small country" did you miss?

hosted gmail

[jasonhamilton]

gmail also has a hosted solution. you sign up, point your dns to gmail's mail servers, and can have all your email go through email. You can even create accounts, mailing lists, etc. Right now they appear to be limiting me to 25 users per domain. Works really well. you can pop3 off their system too.

Re:hosted gmail

[arunkv]

gmail also has a hosted solution. you sign up, point your dns to gmail's mail servers, and can have all your email go through email. You can even create accounts, mailing lists, etc. Right now they appear to be limiting me to 25 users per domain. Works really well. you can pop3 off their system too.

Wow - that's cool! I didn't know about Google's free hosted apps for domains. For those looking to signup, check out https://www.google.com/a/

Re:hosted gmail

[batkiwi]

They also give you free jabber hosting if you edit your SRV records.

It is GMail's fault

[Anonymous Coward]

If GMail is doing "call-backs" to prevent forged senders, it is their fault. That is not the right way to authenticate senders on the internet. They should be using SPF to authenticate the sending server, first. Only if that is unsuccessful would you want to attempt a "call-back" and even then, a "call-back" is not generally considered an acceptable sender authentication mechanism. It is a hack on SMTP that somebody thought up, but, as illustrated by this issue, is not compatible with other anti-spam measures used by some email admins. Sourceforge is using SPF, as shown in their TXT DNS record below, so GMail should NEVER do a "call-back" for any sender from that domain.

SPF DNS record for "sourceforge.net":
v=spf1 mx a:mail.marblehorse.org a:sshgate.sourceforge.net a:mx-outbound.sourceforge.net a:lists-outbound.sourceforge.net a:sc8-sshgate.sourceforge.net a:smtp.vasoftware.com a:newcastle.devrandom.net -all

Google mail forwards.

[rasjani]

While i understand that this post will be read by noone because im not writing this to the topic thats still hot, i'd like to share my experiences. *Gmail* Looses Forwarded Mails. Sometimes. I have my domain thats *now* being hosted in gmail. At one point when my domain was not in use due to outtake on my internet connection, i started to use regular gmail xyz.zxy@gmail.com, about 6 months later, my domain was "accepted" to the beta phase of gmail for your own domains. As i was allready so used to that account and had all my calendar there, i just forward all my mail from my own domain to regular gmail account - and *alot* of messages never reach from One gmail account (hosted) to Another Gmail account (normal gmail). All the messages are visible ofcourse where they first come into the system but they are never delivered to the main account where im supposed to read'em.

Re:Google mail forwards.

[JKConsult]

My email address is xyz.zxy@gmail.com, you insensitive clod!

IT'S FIXED!!!

[SiliconEntity]

Emails I sent a few days ago have now appeared on the SF.NET mailing lists, as of this morning! So it appears that the problem is fixed, or at least that one of the many workarounds that have been suggested have been applied (like temporarily disabling callbacks).

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?

Re:Not Google's only screwup

[bstempi]

Google AsSense

So, is that Google's way of diagnosing hemroids, or of helping you find gay blind dates?

Re:Loss of communication can only mean one thing..

[caseydk]

Hmm... take down one of the biggest Open Source Software repositories and the biggest search engine?

This must be the work of Microsoft!

Now how can we fit Haliburton into this?

gmail rejects too many messages

[ColinPL]

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.

The error message is:

550-5.7.1 Our system has detected an unusual amount of unsolicited
550-5.7.1 mail originating from your IP address. To protect our
550-5.7.1 users from spam, mail sent from your IP address has been
550-5.7.1 rejected. Please visit
550-5.7.1 http://www.google.com/mail/help/bulk_mail.html to review
550 5.7.1 our Bulk Email Senders Guidelines.

Re:Loss of communication can only mean one thing..

[Anonymous Coward]

God bless you!

Re:Why not just dump GMail?

[generic-man]

Results 1 - 8 of about 24 from slashdot.org for "gmail is still in beta". (0.09 seconds)

Results 1 - 10 of about 209 from slashdot.org for "is still in beta". (0.09 seconds)

Fixed

[/ASCII]

I had this issue until yesterday. Today, I've been able to send mail from my Gmail account to an sf list just fine.

Maybe is is Microsoft

[Bob 4knee]

I use a separate gmail account for one of my classes. Last week the students had to mail me an assignment. All of the mail sent from a hotmail account was delayed (still hasn't shown up). All of the email from other accounts arrived. Several hours after the deadline, hotmail informed the students of the delay.

Re:Maybe is is Microsoft

[Achromatic1978]

Fairly standard practice. 99.98% of mail servers in the world won't send a delay notice until four hours - why blame MS?

my sf account never forwards

[Paralizer]

I've setup my SF preferences to forward messages from @users.sourceforge.net to my gmail account. Since I've signed up for gmail, none of the messages sent to my sf address have been received. I always meant to put in a ticket at SF, but never really considered it a big deal, I would just direct people to email my gmail account directly.

Re:my sf account never forwards

[chris.evans]

google gmail is ownd by the cia and all ur messages are seen.

Re:Loss of communication can only mean one thing..

[alx5000]

I'm sure there's a NO CARRIER joke around waiting for me to come across it...

No they don't

[Just Some Guy]

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.

Re:You have never had experience with this problem

[Anonymous Coward]

Nice job on LedgerSMB... very impressive.

Re:Not Google's only screwup

[Anonymous Coward]

Sheeeeeit, my half chewed sandwich is all over the keyboard...

No, it's not

[einhverfr]

And it is MY support request that is linked to in the summary :-)

I sent a test message to the email lists I administer and they have not shown up either in my other account (on the lists too) or in the archives.

All mail gets back to me from the lists, but I can't post. So the summary is pretty misleading too.

The problem is with SF.Net's spam control measures.

Yes, but for a different reason

[einhverfr]

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.

Re:Yes, but for a different reason

[Precision]

Actually the callbacks we do are completely SMTP compliant with the RFC. This is a simple problem on Google's side where some of their MXs are failing causing our callbacks to fail, which in turn causes us to reject the message.

Re:Yes, but for a different reason

[einhverfr]

I am not contending that you are not following standards in this case, however:

1) I have no difficulty forging emails on SF.Net lists. So this doesn't stop spam.

2) It is brittle for large installs (like Gmail).

3) You folks aren't even willing to document what the minimum requirements are for us to connect our own Qmail servers. I am having similar issues in my own servers and can verify that even though mail gets to me properly (meaning the MX records are working fine), you are still refusing them at the callback unless I use a third party email proxy not listed in my MX records (like mail2web).

Just because you are following RFC's doesn't mean that you are implementing things in line with structures outlined in the RFC's. In this case you are breaking things.

It is *my* support request linked to in the summary. This has been going on for a week and you folks aren't willing to fix the problem. It is *extremely* frustrating as the admin of a number of projects.

Google Code hosting is looking better and better.

Nope

[einhverfr]

And it is my support request in the summary :-)

Not just that...

[einhverfr]

One can use VRFY for a simple address harvesting system :-)

Lot o'spam here we come.

I can't believe that SF.Net is forcing people to allow this sort of thing.

And, for the record, it is my support request in the summary.

Another big company

[caluml]

There's another big company that doesn't configure its mail servers/dns entries properly too.

Sep 26 03:11:47 hosting postfix/smtpd[19263]: connect from mail7.exchange.microsoft.com[131.107.1.27]
Sep 26 03:11:49 hosting postfix/smtpd[19263]: NOQUEUE: reject: RCPT from mail7.exchange.microsoft.com[131.107.1.27]: 450 4.7.1 <df-gwy-07.exchange.corp.microsoft.com>: Helo command rejected: Host not found; from=<a.user@exchange.microsoft.com> to=<a.user@a.domain> proto=ESMTP helo=<df-gwy-07.exchange.corp.microsoft.com>
Sep 26 03:11:49 hosting postfix/smtpd[19263]: disconnect from mail7.exchange.microsoft.com[131.107.1.27]

The trouble? There's no DNS entry for df-gwy-07.exchange.corp.microsoft.com, and hence Postfix (with reject_unknown_hostname ) slings out the mail.

Re:Loss of communication can only mean one thing..

[maxume]

Haliburton recieved a no-bid contract from the Attorney General to coerce Google into releasing its search data. Haliburton then subcontracted with Microsoft who employed mercenary hackers to carry out the attack.

Re:Loss of communication can only mean one thing..

[DarrylKegger]

I for one reject this hackneyed and cliched joke format.

Honestly i don't know which is worse; this one or imagine a beowulf etc...

GMAIL isn't doing callbacks, Sourceforge is....

[einhverfr]

That is the problem. And SF.net messages to gmail are getting through just fine.

Hope you enjoy spam...

[serodores]

I find it interesting that a topic discussing the useless bouncing of email messages results in another case of useless email messages... One would hope these email addresses weren't real: rodolfo.borges@gmail.com albert@users.sf.net

Google's Usually the Cause

[Anonymous Coward]

With Google, it's generally a good idea to bet on Google being the source of the problem.

why blame MS?

[Anonymous Coward]

Because this is /.

Re:Loss of communication can only mean one thing..

[dkf]

It's not a problem. Use "+1 Informative" for that instead.

Re:Loss of communication can only mean one thing..

[caseydk]

You make me proud young padawan.