Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

DynDNS Drops Non-Delivery Reports

kdawson posted more than 7 years ago | from the one-less-spam-vector dept.

Spam 195

jetkins writes "In an email to subscribers, DynDNS announced that they will no longer deliver locally generated non-delivery reports (NDRs) from any MailHop systems. MailHop is a multi-faceted service offering in- and outbound relay services, spam and virus filtering, and store-and-forward buffering. DynDNS makes it clear that they are aware that this goes against RFC 2821 Section 3.7, but explains that in their opinion the increase in spam volume, and the use of NDRs as a spam vector, means that the value of NDRs is now far outweighed by their potential for harm. (DynDNS also points to the far greater reliability of email systems now than when the RFC was approved.) The company notes that other ISPs have quietly dropped RFC 2821-compliant NDRs. Will their public move start a flood (mutiny) of ISPs following suit? Should they have made efforts to have the standard changed instead of defying it?"

Sorry! There are no comments related to the filter you selected.

Finally, a service provider with a clue... (4, Informative)

Eggplant62 (120514) | more than 7 years ago | (#20347569)

Well, seeing as how a friend and I have a client who's being bombarded by NDRs as a result of a joe-job on the client's domain name, it's good to know that DynDNS is copping a clue. Too bad you can't get the rest of the ISP gang on board that easily and that quickly.

Re:Finally, a service provider with a clue... (5, Informative)

jetkins (1049838) | more than 7 years ago | (#20348089)

A large proportion of Joe Jobs are made possible by lame endpoint SMTP servers which accept incoming mail, close the connection, then check to see if the recipient is valid, and generate an NDR to the address specified in the headers, which are too easily forged.

A properly-configured endpoint server should check addressee validity during the SMTP exchange, and reject the transfer before it even gets into the system, so the spammer's attempt goes nowhere and "Joe" doesn't get an unwarranted NDR.

Of course that doesn't help proxy providers like DynDNS, unless they have some way of authenticating their clients' valid addresses in real time via a direct connection or regular updates.

Re:Finally, a service provider with a clue... (2, Insightful)

bvimo (780026) | more than 7 years ago | (#20348463)

Isn't it time we changed something. Amended or created a new RFC, or design mail servers that don't talk to poorly implemented servers.

/. commentators have spouted enough hot air about Joe Jobs, Non Delivery Receipts etc, we should stand up and do something.

Re:Finally, a service provider with a clue... (3, Informative)

r3g3x (1147243) | more than 7 years ago | (#20348181)

Well, seeing as how a friend and I have a client who's being bombarded by NDRs as a result of a joe-job on the client's domain name, it's good to know that DynDNS is copping a clue

Ignoring a problem isn't the same as fixing it... NDRs serve a useful purpose assuming the original message was actually useful. The problem isn't sending out NDRs. The problem is sending an NDR in response to spam!

I've had to deal with the whole joe-job+NDR+DDOS scenario on several occasions... I have found that 65~80% of this garbage has already been marked as spam by the bouncer! Why in the would would you bounce a message that you _already_ know to be invalid?!?!? All this does is amplify the volume of crap being flung around...

A sanely configured email server should not bounce on spam. Spam should be left to rot in the bottomless pit of /dev/null.

Remember, Its not a turd fight if theres only one monkey :-)

Re:Finally, a service provider with a clue... (1)

Eggplant62 (120514) | more than 7 years ago | (#20348437)

Well, let's see. The friend consults me for help on mail problems. He says that the customer won't accept changes in his system to something more reliable and easier to configure, and since he's paying the bills and won't foot for the changes necessary, it sounds like we're living in la-la land already, so an easy solution isn't going to be easy.

I'm certain you've seen the syndrome: Speak to the business owner and his management team about the problem in easy-to-understand terms, and their eyes glaze over like you're speaking Greek about Pythagorean theory and then decide that if it's not Microsoft Brand software, it's not gonna go into their systems. Copy there, Ace?

What I'd like to see... (2, Interesting)

SomeJoel (1061138) | more than 7 years ago | (#20347589)

In addition to not providing NDRs, it would be great if the ISP took the following approach: If 5 or more non-deliverable messages to different addresses within the ISP's domain are received within a period of 10 minutes, then the sender's IP address should be blocked for a period of 24 hours. That, I think, would do a small bit to slow down the spam.

Re:What I'd like to see... (4, Insightful)

AuMatar (183847) | more than 7 years ago | (#20347675)

And kill mailing lists. Not all mass mails are spam.

Re:What I'd like to see... (2, Insightful)

Chyeld (713439) | more than 7 years ago | (#20347889)

as well as providing a fairly simple manner of performing DOS against a domain, simply spoof your way into seeming to be their mail server and slam in the garbage.

Re:What I'd like to see... (1)

profplump (309017) | more than 7 years ago | (#20348051)

That's a non-trivial attack though -- it's not as though you can send mail with uni-directional traffic.

In order to spoof a remote IP address you'd have to basically have to share a wire someplace between the mail server and your spoofing target, or exploit some secondary flaw on a router/host along that same path. It could be done, but there are easier ways to DoS, and most of those ways are effective beyond the single-host-to-single-mailhost-for-mail-service-on ly scope that is targeted with the attack you describe.

Re:What I'd like to see... (1)

quanticle (843097) | more than 7 years ago | (#20348347)

That's a non-trivial attack though -- it's not as though you can send mail with uni-directional traffic.

You don't have to send mail with unidirectional traffic. You just have to make sure that the traffic doesn't point back to you. In other words, if you send mail from a botnet, you're still free and clear as long as you don't use too much of your botnet at once.

Re:What I'd like to see... (1)

profplump (309017) | more than 7 years ago | (#20348603)

That doesn't create a DoS for anyone other than your botnet, which effectively *is* you if you're using the botnet to do things on your behalf. And somehow I don't think "DoS with the scope of a single mail host" is the biggest concern of someone who's box has become part of a botnet.

I'm not suggesting you couldn't get some box other than your own desktop blocked, or that blocking by IP would be effective at stopping spam. I was just refuting the original statement that you could use IP-scoped blocking in response to mail message content as an effective DoS attack.

Re:What I'd like to see... (1)

wiredlogic (135348) | more than 7 years ago | (#20347845)

This scheme would be useless against a distributed botnet attack.

Re:What I'd like to see... (1, Funny)

Anonymous Coward | more than 7 years ago | (#20347921)

This scheme would be useless against a distributed botnet attack.
It would be useless against a mechanical Richard Simmons attack, too.

I do that. (1)

khasim (1285) | more than 7 years ago | (#20348723)

I've always refered to that as a "phone book attack".

After X failed addresses, block the sender.

Except you have to make exceptions for things like gmail and hotmail and other major ISP's and mail delivery services.

Instead of sending and NDR though, I just reject at SMTP time. If the ISP's were a bit smarter, they'd see X rejections (5xx-series) and shut down ALL outbound email from that account.

And I want a pony and a plastic spaceship and ...

RFC-Ignorant.org (4, Interesting)

nagora (177841) | more than 7 years ago | (#20347591)

I did this some time ago for the same reasons and the wankers at RFC-Ignorant.org put my home email server on their blacklist. The twats argued with me that NDRs are such a vital part of email that any amount of spam was a price worth paying for maybe one NDR a year.

Stupid bastards.

Re:RFC-Ignorant.org (3, Insightful)

Anonymous Coward | more than 7 years ago | (#20347739)

What's needed is for servers to start determining immediately whether they can deliver the mail or not and respond to the sender with an appropriate error code if not, instead of sitting on it for a few hours and then creating a bounce message. This can even work over multiple hops if the sending server isn't an open relay, the destination server replies to your ISP's mailserver with "550 Cant send shit captain!", and leave it up to your ISP to decide to retry, generate a bounce to you (which it should have no problem doing, after all, everyone sending email through its server has an account at the ISP, right?), or just drop the matter in the bit bucket.

Once that initial connection is gone though, the receiving mailserver should not assume that it has any way to talk to the sender again.

Re:RFC-Ignorant.org (0)

Anonymous Coward | more than 7 years ago | (#20348445)

What's funny about this? I think it's a good idea.

Re:RFC-Ignorant.org (2, Insightful)

Jeff DeMaagd (2015) | more than 7 years ago | (#20347749)

I don't see the point in dogmatically upholding a rule for its own sake. If a rule doesn't always make sense, then change it. An RFC for RFC's sake doesn't do us any good unless the principles in it are still a good idea. Having said that, I think RFCs in general a bit baffling, harder to comprehend then legislation.

Re:RFC-Ignorant.org (0)

fm6 (162816) | more than 7 years ago | (#20347821)

I don't see the point in dogmatically upholding a rule for its own sake.
You're new around here, aren't you?

Re:RFC-Ignorant.org (1)

cgori (11130) | more than 7 years ago | (#20348305)

You're new around here, aren't you?


Based on a 4-digit SlashID, I'd say not...

Re:RFC-Ignorant.org (1)

Applekid (993327) | more than 7 years ago | (#20347869)

If a rule doesn't always make sense, then change it.
So I wonder, why DynDNS and the others are just doing it without going through the effort of having it changed?

It's easier to get forgiveness than permission, I suppose.

Re:RFC-Ignorant.org (1)

fm6 (162816) | more than 7 years ago | (#20347785)

You're an evil person! I'll bet your whois record doesn't even have your correct email and phone number!

Re:RFC-Ignorant.org (3, Informative)

flabbergasted (518911) | more than 7 years ago | (#20347791)

Why are you accepting a message for a nonexistent user in the first place? As soon as the sending SMTP connection specifies RCPT you should be able to check if it is valid and terminate the connection if it is for a nonexistent user. This can all be done before the DATA command is issued. Why waste cycles virus scanning, spam screening and bouncing a message for a user you don't even have? You're not just RFC ignorant, you're ignorant of how to properly run a mail server!

Note that the method above gets rid of NDRs for nonexistent users but still provides them for a user over their quota or suffering other delivery problems.

Re:RFC-Ignorant.org (3, Insightful)

plague3106 (71849) | more than 7 years ago | (#20347927)

That's a great way to determine VALID accounts to spam.

Re:RFC-Ignorant.org (1)

TheLinuxSRC (683475) | more than 7 years ago | (#20348307)

That's a great way to determine VALID accounts to spam.

Possibly, but it does prevent the backflow DOS problem.

Re:RFC-Ignorant.org (2, Informative)

mrjackson2000 (733829) | more than 7 years ago | (#20348535)

there are ways to avoid this problem also, or atleast lessen the impact. my server will watch for non existant addresses being tried from a single ip, when a threshhold is hit the server drops the connection, i can then block that ip via tcp.deny or any other method and they cannot try again.

Re:RFC-Ignorant.org (3, Insightful)

fimbulvetr (598306) | more than 7 years ago | (#20348685)

That's a great way to determine VALID accounts to spam.
A lot of people bring up this point, but it's only ostensibly helpful anyway. The resources you save from not verifying an address are _quickly_ eaten up by the fact that you're queueing messages for invalid addresses on your domain at oftentimes insane rates. Pretty soon, your lame server is going to start to deliver these zillion+ NDRs and not only ruin the rest of your day for your users by stealing bandwidth and mail server resources, but also for many, many other people on the internet who need to delete the 80+ NDRs you sent them.

So USE that information. (4, Insightful)

khasim (1285) | more than 7 years ago | (#20348777)

Yes, the spammer can determine whether it has a valid account. But that means ...

#1. The spammer already HAS the account name and is checking to see if it still works. Defeat this by generously distributing SpamTrap accounts. And accepting email to them. And then opt'ing out of the email that they receive.

#2. The spammer is trying to guess a new name. Good luck with that. Sure, maybe SOMEWHERE there is an email account of "frank@example.com" but good luck finding it. If you want to have some FUN, watch your logs for examples of this. Then setup some of them as SpamTraps. And follow #1 above.

I use both of these approaches. It makes filtering spam VERY easy.

Re:RFC-Ignorant.org (0)

Anonymous Coward | more than 7 years ago | (#20348859)

So smile and nod your head while ignoring the whole thing and hoping it goes away. Works for my boss.

Re:RFC-Ignorant.org (2, Insightful)

dondelelcaro (81997) | more than 7 years ago | (#20349425)

That's a great way to determine VALID accounts to spam

If someone is going to pull off a dictionary attack against the SMTP server, then you just discard connections to them after a specific number of invalid users.

Almost all mainstream MUAs support this sort of thing now.

At the end of the day, if you actually accept the message for delivery and later reject it, you should do so silently.

Re:RFC-Ignorant.org (2, Informative)

aaronl (43811) | more than 7 years ago | (#20347971)

If you're a backup mail exchanger, then you must accept mail on behalf of the primary mail server, and relay to it later. You don't necessarily have any way to verify the account as valid at that time. If you don't do a NDR, then the message originator has no way to know that an error occurred when the backup MX tried to relay into the primary.

Re:RFC-Ignorant.org (1)

Menchi (677927) | more than 7 years ago | (#20348329)

All SPAM Mails go directly to the secondary MX host. Ok, not all, something like 98%. I seriously considered to configure my secondary MX with a deny all rule but instead I just add a lot of points to the SPAM-Assassin score and reject the mail if enough points are reached. And there are ways to check if a recp to address is valid on your secondary MX, but that depends on your setup.

Re:RFC-Ignorant.org (2, Insightful)

gi-tux (309771) | more than 7 years ago | (#20348455)

And this is exactly the case with DynDNS and their MailHop service. They will receive email for many folks that are behind and ISP that blocks all incoming traffic on port 25. Then they will relay it to the server on a different TCP port, such as 52525. So if I were a customer of DynDNS and someone sent me an email but misspelled my username (gitux instead of gi-tux), then a problem is going to happen. DynDNS accepts the email which was intended for me (but the wrong username). DynDNS then forwards the msssage to my correctly configured server, which tells them that this user does not exist. They drop the message and do not return and NDR. Now someone believes that I have received the email that was sent to me because they did not get an NDR. However I didn't see the message nor is there any indication to me that anyone tried to send me a message.

I see this as causing more people to be sending messages with delivery/read receipts so that they will know that the message was properly delivered and/or read. I am afraid that this will lead to an increase in traffic due to these receipts being requested more. But then I guess that servers will start dropping the receipts as well and then sending an email will be no more reliable than sending a snail mail. It is supposed to be a guaranteed system of delivery, but there is a huge dead letter barrel that gets way too many things.

Re:RFC-Ignorant.org (3, Informative)

Menchi (677927) | more than 7 years ago | (#20348767)

There's even a solution for this kind of problem: It's called "recipient callout". The proxy SMTP Server will attempt a fake delivery attempt to the endpoint SMTP server before OKing a recipient. If it succeds, OK it, if it fails, deny it. Sure it costs some resources, but less than a bounce. And if you don't have enough resources to run an email server, don't run an email server.

Re:RFC-Ignorant.org (1)

redelm (54142) | more than 7 years ago | (#20349441)

What ISPs block 25 inbound? What exploit are they trying to prevent? 'dozy boxen aren't running anything on 25. Legit SoHos with static IPs certainly need 25 in.

Many ISPs block 25 outbound to be good netizens and avoid their lusers'botnets spewing spam. Legit users can get the block lifted.

Re:RFC-Ignorant.org (1)

Eggplant62 (120514) | more than 7 years ago | (#20348109)

Real mailers do that. Some folks, for odd, unknown reasons, keep using mail systems that refuse to do those things you specified, which started and continue to propagate the problem. Until we can get them to change to real mail server equipment, extreme solutions like ignoring RFCs seems to be the only way to find solace.

Re:RFC-Ignorant.org (0)

Anonymous Coward | more than 7 years ago | (#20349487)

As soon as the sending SMTP connection specifies RCPT you should be able to check if it is valid and terminate the connection if it is for a nonexistent user.

Email addresses don't have a 1:1 mapping with users. I use sitename@example.com when I register on a website, and everything@example.com gets sent through to my account. So how am I going to determine whether foo@example.com is valid or not? You suggest manually setting up a redirect for each and every website I visit? No thanks.

You're not just RFC ignorant, you're ignorant of how to properly run a mail server!

Fuck you. Just because somebody's use pattern isn't identical to yours, it doesn't mean they are wrong or ignorant. In fact, if you haven't even considered this possibility, I'd bet you haven't run a mail server yourself.

Re:RFC-Ignorant.org (1)

megaditto (982598) | more than 7 years ago | (#20347859)

Am I the only one here that likes NDRs? If some important email is not delivered, I would much prefer that a sender is notified about that failure. Wouldn't you?

Outright NDR ban is just plain stupid, akin to curing headaches with guillotine. If they must do something, why not place a cap and delay on the NDR traffic.

Re:RFC-Ignorant.org (1)

the_humeister (922869) | more than 7 years ago | (#20348009)

Am I the only one here that likes NDRs?


Yes

Re:RFC-Ignorant.org (1)

nuzak (959558) | more than 7 years ago | (#20348067)

Proper mail servers bounce during the SMTP session. Even AOL has LDAP integration so they can bounce during the SMTP session. If they can do it, anyone can. DynDNS is simply no longer doing accept-and-bounce, which is a GOOD thing. That they're not moving to an architecture that would prevent accept-and-bounce isn't so hot, but considering what they are, I don't see how they could. This makes them one of the few organizations that actually has an excuse.

I'm not one of the people that shouts how "email shouldn't be considered reliable", harkening back to the "good old days" when email was routinely eaten or delayed for days, but in a purely technical sense, email isn't a reliable datagram transport, and even though the RFC has a bunch of MUSTS (like 3.7) about reliable indicators, this is not enforced by the protocol. You have no guarantee that any human at the end even reads it anyway. Double these caveats when you're sending to such a chewing-gum-and-baling-twine type of infrastructure as a DynDNS hosted server.

Re:RFC-Ignorant.org (0)

Anonymous Coward | more than 7 years ago | (#20348521)

If some important email is not delivered, I would much prefer that a sender is notified about that failure. Wouldn't you?
Yes, but NDR isn't the only way to do this.

Re:RFC-Ignorant.org (1)

Desert Raven (52125) | more than 7 years ago | (#20348929)

Am I the only one here that likes NDRs?

Probably

The concept is nice, but I get scores of them every day from ignorant mailservers telling me that the spam that I didn't send, but had my address on it didn't get delivered. I filter them off into a folder, which frankly, I just purge every week or so. I don't have the time to read through them.

Re:RFC-Ignorant.org (1)

megaditto (982598) | more than 7 years ago | (#20349243)

You are being smart about NDRs: they do not work for you, so you filter them out. If another user needs them, they pay attention to them.

NDR ban sounds like a solution in search of a problem which will hurt legitimate users if this thing catches on.

Re:RFC-Ignorant.org (1)

dskoll (99328) | more than 7 years ago | (#20348105)

RFC-Ignorant doesn't "blacklist" anyone. It just informs people that such-and-such-domain does not follow a particular part of an RFC.

Re:RFC-Ignorant.org (1)

Ant P. (974313) | more than 7 years ago | (#20348353)

A blacklist for IPs that disobey RFCs? Whoops, there goes 255.255.255.255/0 for ignoring the IPv6 RFC. Whoops, there goes ::/0 for deliberately ignoring the Type 0 header spec in the IPv6 RFC.
Utterly retarded idea, and an utterly worthless list.

Re:RFC-Ignorant.org (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#20348935)

I haven't seen anyone try to be funny and fail so hard at it in years. Even your sig is a flop.

Re:RFC-Ignorant.org (1)

+Addict-09+ (239664) | more than 7 years ago | (#20348415)

I've had problems with those idiots as well

Re:RFC-Ignorant.org (1)

Vancorps (746090) | more than 7 years ago | (#20349539)

My domain was added back in 2002 when it was hosted by an ISP that is now bankrupt. why should I be concerned about being blacklisted by them? Does anybody use them for filtering?

Change or Defy (4, Insightful)

Astrogen (16643) | more than 7 years ago | (#20347639)

While I do believe they should initiate an effort to update the standard, if they view it as a security threat or a spam vector they are entirely right in shutting down the service.

If a RFC said all boxes should have a port that users could telnet into with root access, and people start abusing that would you leave it and wait for the standard to change?

No (1)

The MAZZTer (911996) | more than 7 years ago | (#20348439)

I would find whoever wrote the stupid standard and make sure they are incapable of drafting any more standards in the future.

Re:Change or Defy (1)

the_humeister (922869) | more than 7 years ago | (#20348453)

You know, I don't see anyone following this RFC [sunsite.dk] . So, as it stands, it seems these RFCs aren't always adhered to.

Re:Change or Defy (1)

cstdenis (1118589) | more than 7 years ago | (#20348595)

I use RFC 2549 you insensitive clod.

SPF? (4, Insightful)

Southpaw018 (793465) | more than 7 years ago | (#20347653)

If SPF were more widely implemented, or required to be implemented, wouldn't this problem be solved? Don't send NDRs to domains without SPFs or when SPF fails. NDRs get through and problem solved.

And what DynDNS is doing is simply preventing all people from using their service from knowing whether email is being delivered properly. If I typo an email address, I damn well better be getting an NDR from the recipient domain, because simply having it go into an email black hole and never knowing whether it got there is not an acceptable alternative.

Re:SPF? (1)

Sircus (16869) | more than 7 years ago | (#20347685)

If you typo an address, the receiving mail server should be able to reject it during the SMTP conversation. This should result in an NDR for you from the sending mail server.

Re:SPF? (0)

Anonymous Coward | more than 7 years ago | (#20348501)

Dude, that was his point. If they aren't sending NDRs he won't get one.

Re:SPF? (1)

TheSkyIsPurple (901118) | more than 7 years ago | (#20348759)

Some places are set with their external servers as dumb as possible... they know nothing about whose accounts are valid or not, so if they ever do get hacked, you don't have all legal addresses available for mailings lists, sales, etc...

Granted, you can pick up alot from logs, but not all

Re:SPF? (1)

jchawk (127686) | more than 7 years ago | (#20347767)

If you send to an address at one of my corporate domains that is incorrect you're not getting an NDR.

Your email will go into a catchall mailbox and it will be forwarded to the appropriate person. Yes this is tedious however 1 missed email could be a missed chances at *TONS* of business. Often times people won't email you again if they get an NDR back.

Re:SPF? (1)

ajs (35943) | more than 7 years ago | (#20348351)

If SPF were more widely implemented, or required to be implemented, wouldn't this problem be solved?
Yes.

Don't send NDRs to domains without SPFs or when SPF fails.
A fair point.

And what DynDNS is doing is simply preventing all people from using their service from knowing whether email is being delivered properly. If I typo an email address, I damn well better be getting an NDR from the recipient domain, because simply having it go into an email black hole and never knowing whether it got there is not an acceptable alternative.
Welcome to 2007. I hate to say it, but this is the state we're in. When I used mailhop, I used it for secondary MX, so I would not really have cared too much about the off chance that when my primary MX was down, you sent mail with typo in the To address. Failure recovery doesn't need to be 100% perfect for me to appreciate having it.

Re:SPF? (0)

Anonymous Coward | more than 7 years ago | (#20349199)

I simply don't send "Out of office" or NDR's if SA score >7.

I like SPF a lot... (1)

msimm (580077) | more than 7 years ago | (#20348465)

But I don't think it's a solution. Between softfails, ISP's who block outgoing connections to port 25 (in favor of using their own SMTP servers) and generally low scoring on most spamassassin configurations I've seen I'd consider it helpful (particularly in getting your email OUT) but not a definitive answer.

That said I DO wish more people would use it so that it's overall impact would be increased (as people began to rely on it more). TMDA aside (which has a whole batch of problems, I know) it's my next favorite tool.

Re:SPF? (1)

trolltalk.com (1108067) | more than 7 years ago | (#20348899)

"If I typo an email address, I damn well better be getting an NDR from the recipient domain,"

And if your typo matches a real person's email, you won't be getting an NDR. Heck, I've gotten tons of email from people who have sent their stuff to the wrong person - including the new password for someone whose name misses mine by one letter.

If the mistake originated with you, don't expect someone else to take responsibility for fixing it.

Re:SPF? (1)

kindbud (90044) | more than 7 years ago | (#20349581)

If SPF were more widely implemented, or required to be implemented, wouldn't this problem be solved?

No, SPF/Sender-ID are bad ideas, which even their creators don't put much trust into. Don't believe me? Try sending a brand-new newsletter to Hotmail and MSN subscribers. Make sure all your Sender-ID and SPF records are in place and verified with Microsoft's own Sender-ID checker. Make sure all your WHOIS data is current, valid and not obfuscated for privacy. Setup your mail servers on freshly-allocated netblock, which you've verified is not on any DNS blacklists. All your ducks are in a row, so you send your newsletter with high hopes. They will be dashed. Microsoft will stuff your newsletter in the Bulk Mail folder anyway, until their servers "get used to" your mail stream. Even Microsoft places no stock whatsoever in Sender-ID. It is a waste of time, a means of dismissing your attempt to interoperate with them. Sender-ID is just another way for Microsoft to tell you "Not enough dick sucking, try harder."

to defy the laws of tradition (4, Insightful)

chef_raekwon (411401) | more than 7 years ago | (#20347687)

Should they have made efforts to have the standard changed instead of defying it?

maybe by defying it, the standards will now be reviewed, and eventually changed.

Re:to defy the laws of tradition (1)

SnoopJeDi (859765) | more than 7 years ago | (#20348039)

That's what the confederates thought.

Re:to defy the laws of tradition (1)

Breakfast Pants (323698) | more than 7 years ago | (#20348677)

And what Martin Luther King, Jr. thought (correctly, though he got the idea from Gandhi, not the confederates).

Re:to defy the laws of tradition (1)

rhizome (115711) | more than 7 years ago | (#20349559)

maybe by defying it, the standards will now be reviewed, and eventually changed.

And your daily lesson in passive aggression comes to you from chef_raekwon today.

Not very Wu of him, if you ask me.

RFC (2, Funny)

networkzombie (921324) | more than 7 years ago | (#20347695)

Setup the NDR delivery to cc the postmaster. That'll force him to block those emails during the session rather than letting them get through. Let's face it; if you're getting too many NDRs, you are accepting email from illegitimate sources that need to be blocked. It will stop the joe-jobs and allow the legitimate NDRs to continue. I'm gonna build my own RFC 2821, with hookers and blackjack.

Re:RFC (1)

Seakip18 (1106315) | more than 7 years ago | (#20347799)

In fact, forget the RFC 2821 and blackjack!

Re:RFC (1)

discord5 (798235) | more than 7 years ago | (#20348819)

Aaaah, screw the whole thing

The Problem Is Not NDR's (4, Insightful)

jchawk (127686) | more than 7 years ago | (#20347719)

It's email in general. The whole system is flawed and we've tried repeatedly to duct tape over the problem.

The main problem is a you have a system based on blind trust.

Second trust based duct-tape systems are simply too cumbersome for the average user.

I don't have the answer but I do know that email in it's present state is broken.

Start at the top, with secure DNS. (1)

Colin Smith (2679) | more than 7 years ago | (#20348167)

It has to start with secure DNS. Receiving mail servers have to be able to test that the originating mail server actually represents the domain it says it does.

 

Re:Start at the top, with secure DNS. (0)

Azghoul (25786) | more than 7 years ago | (#20348255)

And all that does is fuck over any legitimate emails that don't come from the domain in the reply-to, screwing home-installed linux users.

No thanks.

Re:Start at the top, with secure DNS. (3, Informative)

greed (112493) | more than 7 years ago | (#20348425)

Way to confuse envelope-from, header-from and reply-to.

Besides, my home-brewed Linux-based mail server has a published SPF record, and anyone receiving mail can verify that machine is entitled to generate envelope-from with that domain. The SPF also spells out my relay provider, since my DSL line is in DSL blocklists.

What it really needs, at the least, is for people to stop accepting bogus HELO/EHLO addresses and other unverifiable envelope information. If there isn't even an A record for the HELO address, then 554 the message.

This means mail from many large corporations will be rejected, because they use HELO hostnames that only resolve inside the company.

Re:Start at the top, with secure DNS. (1)

Colin Smith (2679) | more than 7 years ago | (#20348449)

It just means the mail server needs a valid DNS domain and to have it set up securely. It's not so difficult and is badly needed. It solves much of the spam and phishing problem.

 

Re:The Problem Is Not NDR's (1)

Eggplant62 (120514) | more than 7 years ago | (#20348177)

...email in it's present state is broken.


I'm reposting this to make certain that if one point gets made here, this is it.

Re:The Problem Is Not NDR's (1)

Realistic_Dragon (655151) | more than 7 years ago | (#20348447)

I respectfully disagree.

E-mail works fine, with the various hacks that have been added on to fight entropy. Dealing with normal spam is no worse than the annoyances of closed networks - you still get spam on facebook etc!

Compare and contrast e-mail with the alternatives - you get instant messaging, which solves a different problem and *still* sucks, or you place yourself at the mercy of a third party. No thanks.

If you can't use e-mail chances are you don't:

Run an well configured server (or pay an insignificant amount of money to the people at tuffmail to run one for you)
Have a mail client with decent filtering

However NDRs are a major problem. My domain was spoofed this week and I received 30k+ NDR responses. 2k+ ended up in my inbox ... and unlike regular spam they are really hard to filter. I normally get 2k~ spam per week and max 1-2 end up in my inbox.

Re:The Problem Is Not NDR's (1)

poetmatt (793785) | more than 7 years ago | (#20348569)

As someone who doesn't know that much about email,

how am I supposed to know if an email didn't go through correctly now? What if this is a critical business venture? (say a 7-9 figure transaction)
Are there other ways to be notified of an email not being delivered?

Also I understand your "things are broken" complaint but what can be done about it?

Re:The Problem Is Not NDR's (1)

Tim C (15259) | more than 7 years ago | (#20348801)

What if this is a critical business venture? (say a 7-9 figure transaction)

Then if for whatever reason it has to be email, rather than courier, fax, snail mail, in person, etc, you could always pick up the phone and ask for verbal confirmation of receipt, or assume that not getting a reply confirming receipt is evidence of non-delivery.

Anyone who blindly relies on email (or anything else) being delivered, received, understood and acted upon correctly for a critical business venture without some kind of confirmation process is a fool. For example, you won't get an NDR if the user's mail client binned it on receipt as spam, or filtered it off to the wrong folder...

Re:The Problem Is Not NDR's (1)

pkulak (815640) | more than 7 years ago | (#20349601)

I don't know why everyone keeps saying this. Sure, if I apt-get Postfix on my local box it's going to be flooded with spam, but throw SpamAssasin on there, use the spamhause blocklists, and you get just about none. There are only so many servers that should be sending mail. Just block the rest and you're done. Sure that's a bit complicated, but so is all this talk of Email 2.0.

Standards and Implementation (5, Insightful)

LithiumX (717017) | more than 7 years ago | (#20347731)

Tried and true standards make the net go round, but the most effective enhancements or changes to standards usually don't come from a committee working out best practices - it comes from individuals making hard choices on what to support. If those changes turn out to be beneficial, then they become adopted as new standards.

Going against standards can cause a bit of chaos as well, which is why it's good to avoid deviation - but sometimes a deviation makes sense, and you do it. Publicly announcing this (non-critical) deviation, and explaining exactly why, is the proper way to go about it.

Re:Standards and Implementation (2, Insightful)

OldeTimeGeek (725417) | more than 7 years ago | (#20347951)

it comes from individuals making hard choices on what to support. If those changes turn out to be beneficial, then they become adopted as new standards.

The process of modifying standards is a bit more complex [rfc-editor.org] than that, but there is a process for change. You just have to become part of it rather than just picking and choosing which standards annoy you the least and then hoping that someone else will fix the ones that don't work the way you think they should.

Re:Standards and Implementation (1)

Luthe_Faydwire (700369) | more than 7 years ago | (#20348191)

Just to be honest here people do not follow the standards 100%. They build something that works well enough, then most add "value adds". Cisco and BGP are a good example as though they helped write the RFC they also built their code with additional features that made it incompatible in some designs. I think that Juniper built a command that allowed them to run "Cisco BGP" but its been awhile. I don't know the number of times that I have found that system do not work the way that an RFC says they should while the company claims RFC compliance.

Re:Standards and Implementation (1)

_anomaly_ (127254) | more than 7 years ago | (#20348059)

Publicly announcing this (non-critical) deviation, and explaining exactly why, is the proper way to go about it.
I tend to differ...
What they're doing is making a change to a service that they provide so that their problem is resolved (which they have a right to do IMO).
It's kind of a move towards an 'ignorance-is-bliss' policy rather than fixing a problem for their customers... after all, if they aren't aware of a spam problem that their customers are experiencing then there isn't a spam problem.
I'm a fan of DynDNS simply because of the (free) services that they used to provide back in the day that (seemingly) no one else offered, but the way you put it they're leading the industry in solving the Big Email Problem.

Their move will do nothing to impact any standard whatsoever because simply removing the sending of NDRs does nothing to solve the inherent problems, it just covers it up a bit.

Turn off original message in the bounce??? (3, Interesting)

Anonymous Coward | more than 7 years ago | (#20347765)

Did I miss something or wouldn't the problem be solved by turning off the content of the original message in the bounce? If you can't see the original content, it removes the incentive for spammers to use that technique.

This is how it goes on all our mail servers. All bounced messages have the original content stripped off. You get the error message with the reason the message bounced and that's it.

NDR are still usefull. There is PLENTY of mail servers not configured properly or messed up on the Net, even from big ISPs. Calling the current system as a whole, reliable, is a joke.

Re:Turn off original message in the bounce??? (1)

Andy_R (114137) | more than 7 years ago | (#20349175)

It's not just a good idea, here in Britain, it's the law too.

Basically, our spam law says it's illegal to send unsolicited commercial e-mails to private individuals - there's nothing to say that you have to be the author of the spam to fall foul of that law, you are still guilty if you send me an unsolicited commercial e-mail by bouncing it to me from a third party when I'm being joe-jobbed.

A nicely worded 'please change your settings, or I'll tell the information commissioner to fine you £5,000 per mail' e-mail from me has already made a few major businesses and governement organisations change their policy on this, and stop forwarding spam.

Long deprecated in practice (1)

athloi (1075845) | more than 7 years ago | (#20347787)

I knew some ISPs started doing this in the late 1990s after broken mailing lists sending spam from forged addresses generated floods of NDRs in response, smashing the original forged recipient (often some unbelievable sound address like "someone@everywhere.org"). Original NDRs quoted the whole bounced email, but first that changed, then many went to one-liners, and finally, they started disappearing.

they must be running linux (-1, Troll)

Anonymous Coward | more than 7 years ago | (#20347809)

it's ruining modern computing as we know it! what do you expect out of such 3rd rate crap anyway?

not all sending servers can generate NDR (1)

C0vardeAn0nim0 (232451) | more than 7 years ago | (#20347965)

ideally the server sending the message should generate the NDR, this way network traffic would be reduced and delivery of NDRs quicker. for this to work is neccessary that the receiving server runs a directory search for the recipient and replies with a 5xx message (permanent error) after the sending server issues a "RCPT" command.

sendmail and postfix both do this. don't know about MS exchange or courrier. a default qmail install (without patches) certainly don't. i believe there's a patch to implement this, but it's unofficial.

standard qmail accepts and queues anything you throw at it, then pipes the message to another proccess that runs the dictionary search. the result is that if you suffer a dictionary attack (i.e. a spammer takes a huge list of common names - say, 100.000 - and prefixes them to @yourdomain.com), you end up with a thousands of NDRs on your outbound queue, effectively swaping the server and/or connection.

sendmail and postfix in contrast, issue an error if the recipient doesn't exists, which leaves to the sending server the task of creating the NDR, wich IMHO is the correct thing to do.

i wasted too many time cleaning qmail's queue in a couple of servers i inherited from a previous admin untill i got fed up and replaced it with postfix. life is too short to waste cleaning up after spammers.

Are DynDNS cluebies? (5, Insightful)

jani (4530) | more than 7 years ago | (#20348065)

With this reliabity levels of modern e-mail systems being substantially higher than its past predecessors, the practical needs for this NDR messages are nil. These practical, anti-spam, merits far outweigh the prevailing RFC 2822 technical requirements.


Excuse me, but due to the vast amount of spam handling, modern e-mail systems are substantially less reliable than they used to be.

If you redirect email for your domain name to Hotmail, chances are good that it will disappear without a trace. (No NDR, not in the spam box either.)

Someone else already mentioned the problem of people typoing email addresses. This is a common problem.

Email can be bounced for other reasons, too, such as a full mailbox, or that there is a relaying mail server (yes, DynDNS, they still exist, and in abundance!) which gives up on delivery after a week of timeouts for the destination host.

And so on.

Someone at DynDNS needs a good whack with the clue bat.

Problem is legitimate, solution is not (2, Interesting)

EdwinFreed (1084059) | more than 7 years ago | (#20348097)

They absolutely do have a legitimate problem, one that needs to be addressed by appropriate standardization and implementation activities. But unconditionally failing to generate DSNs is not the answer. What they need is a mechanism that eliminates most of the cases where they currently have to generate DSNs.

First, by their own admission this is only a serious problem for what they call their MailHop Backup MX service. Their other services, MailHop relay and forward are "mostly immune" to DSN issues.

The reason for this is simple: With MailHop Backup MX they have no way to validate addresses so they end up accepting a ton of crap to invalid addresses that end up bouncing later when they relay it on. With the other services they can validate addresses and generate a "5yz recipient invalid" sort of error right there in the SMTP session - no need for them to generate a DSN.

So, if the problem is that they don't have sufficient recipient information in the one case, why not solve it by making that information available? One way this could be done is to have the primary MX publish their list of valid addresses using DNS protocols. A zone transfer could then be used to copy the information over so it is available when it is needed. DNS update mechamisms will keep the information reasonably current. (Of course they cannot assume it is current but they can handle that by issuing a "4yz" temporary error instead of a "5yz" permanent one for unknown addresses. Various issues such as needing to support subdomains or subaddresses can probably be dealt with by using NAPTR records. Obviously this whole thing has to be secured and there are various issues with spoofing, but none of these issues seem insurmountable.

Although I think a DNS-based solution could work, I'm really only using it as example. A different mechanism might be more appropriate. But regardless of the mechanism used, what's missing is the set of standards for how different organizations release and consume this sort of information. Without those their customers don't know how to publish the information and even if they did so a backup MX service provider cannot possibly afford to build a custom address import facility for every customer.

It really is past time that people who have such issues stop going their own way and break things when they could be working with others to actually solve the problem. I've brought this issue up in the IETF once or twice and not seen enough interest to pursue it. That might change if folks like DynDNS would get involved.

Re:Problem is legitimate, solution is not (2, Insightful)

Jubal Kessler (7025) | more than 7 years ago | (#20348675)

With MailHop Backup MX they have no way to validate addresses

Not necessarily. Backup MX services could do address validation if they're given a userlist. Of course, this entails some security concerns (example: why trust a backup service with a userlist?), but that can be figured out satisfactorily (answer: use a backup service you can trust, and engineer a secure solution).

Further thoughts:

There is little reason to avoid address validation these days. As for the argument against address validation -- that spammers can determine valid addresses by seeing which ones don't fail, and that's a reason not to validate -- that's not much of an argument:

- Accept and discard, and spammers think all addresses are real.
- Accept and generate an NDR, and spammers never get it, because their sender address/domain is usually bogus.
- Reject unknown addresses, and reduce massive CPU overhead from spam/virus-scanning. Bonus!

Finally, implement some form of connection throttling based on address validation. Some connection's doing what appears to be a dictionary attack, trying a jillion usernames starting with the "a"s? Or even multiple connections doing it, subdividing the alphabet between themselves? Trip a threshold of, say too many connections or too many bad recipients per minute, and refuse further SMTP connections from the given IP address -- or even slip it into a packet-filter rule to blackhole -- for an interval of time, and the problem's solved.

Once spam makes it past the DNS blocklists, the connection throttling, etc. there's enough intelligence in the anti-spam middleware to accurately identify the ham from spam 99% of the time or better.

And of course there's DomainKeys Identified Mail (DKIM) which is now RFC 4871 and is excellent for this middle section of the anti-spam defense wherein one also has to determine whether a message is an elaborate phishing scam or the real deal. SpamAssassin can do a bit of this as well as SPF, etc., and there's a high-performance dkim-milter implementation on sourceforge, too.

SMTP isn't dead, just a tad more complex on the server level, and defenses are improving against the soft areas of the protocol. What I've suggested works pretty darn well as a starting point.

Re:Problem is legitimate, solution is not (1)

Jubal Kessler (7025) | more than 7 years ago | (#20348785)

Whoops. Remind me to read an entire post before replying. I see you've covered what I just said.

I agree that standards to present userlists would help increase adoption of address validation on secondary MXes.

Re:Problem is legitimate, solution is not (0)

Anonymous Coward | more than 7 years ago | (#20349317)

Isn't this what LDAP is for? Combined with SSL and an appropriate access list
would provide the necessary directory services in a secure fashion.

Bad idea (1)

dskoll (99328) | more than 7 years ago | (#20348171)

Unilaterally deciding to ignore an RFC (or part of an RFC) just because you don't like it is almost never a good idea. When Microsoft does it, everyone (correctly!) gets up in arms. DynDNS shouldn't get off any easier.

At most, I would agree with a temporary block of NDRs to a particular user or domain if a large joe-job run is recognized. But this should never be made permanent or blanket.

Having read TFA... (1)

dskoll (99328) | more than 7 years ago | (#20348215)

The problem is one of architecture. There is no excuse in the modern world for running a secondary MX server that lacks knowledge about local recipient addresses. While this architecture may have been OK 10 years ago, it no longer is. Just don't run a secondary MX unless you have a way to transfer your account list to the secondary in a way that the secondary can have local knowledge of valid addresses even if the primary is unreachable.

NDR's are not evil (5, Insightful)

Anonymous Coward | more than 7 years ago | (#20348303)

Throwing out the baby with the bath water comes to mind when I read this...

The problem is not with NDRs. The problem is that their servers *accepted* the message that eventually had to be NDR'd in the first place, then after accepting responsibility, decided they didn't want that responsibility, so discarded mail that they promised they would deliver.

If their servers checked validity of local recipients, scanned and filtered the message, etc BEFORE accepting it (via 2xx series SMTP accept response), and instead properly REJECTED it with a 5xx series response, these messages would never be bounced. The NDR mechanism is not at fault - rather, the fact that they can't properly configure their servers to reject the message up front is at fault. If you properly REJECT the messages at the SMTP level instead of accepting the message for delivery, the only thing left to NDR are perfectly valid cases, such as mailbox over quota, etc.

Once you *accept* responsibility to deliver a message (via a 2xx series SMTP response), you MUST deliver it somewhere, else you have shirked your responsibility - either deliver it to it's destination, or bounce it. To do anything else would be to LOSE mail, which is the ultimate sin of any mail server. The key is not to throw out bounce messages, but to minimize or eliminate unnecessary bounces in the first place by rejecting instead.

Note that by properly REJECTING the message, you also effectively defeat most spam bots, since they can't "bounce" the mail that you reject to the "real" local sender.

I always hate it when providers like this take the short cut of *losing* mail intentionally rather than fixing their broken systems to work right.

One caveat to my comments - unfortunately, some mail software is symply not geared toward todays Internet, such that it can do the scanning and filtering of messages realtime fast enough to prevent a sending server from timing out while it's doing this scanning, so they queue the mail to process it for spam, etc later. Using such software is the first mistake most places make, and is the real reason why there are so many NDR's in the first place.

Re:NDR's are not evil (2, Insightful)

profplump (309017) | more than 7 years ago | (#20348865)

Except DynDNS doesn't have local users, so they can't verify directly that messages will be delivered.

A similar problem occurs when you submit outbound mail to your ISP -- unless it's going to someone else at the same ISP, the local SMTP server can't verify that delivery will succeed. At the ISP level it's still probably reasonable to generate bounce message, at least for local users. That way you don't have to do the final delivery right away, users can still get error messages, and you don't risk sending bounces across the Interwebs.

But it gets tricky for forwarding hosts like DynDNS. The only way to reject during the session would be something like:
A) Inbound connection sends message to forwarding server
B) Forwarding server leaves connection open after the DATA command
C) Forwarding server forms outgoing connections to every domain specified in the envelope addresses
D) Forwarding server attempts to deliver the message to all final recipients
E) Forwarding server rejects original connection from (A) if any deliveries in (D) fail

And even if you overcame the technical complications of such a system, it completely dis-allows the use of mail hosts that don't have 24/7 availability. Moreover it eliminates the ability to use secondary hosts, because even if they can validate addresses (which is not trivial) they can't guarantee things like available disk space on the destination server.

Rejecting messages in-session is certainly a good idea, but it's ridiculous to think that it's possible to eliminate bounce messages just by validating local addresses before accepting a message.

Don't send NDRs for spam. Do send NDRs for ham. (0)

Anonymous Coward | more than 7 years ago | (#20349121)

This case involves a backup MX for third parties. So it's rather unusual, and the rule that should apply 99% of the time ("don't accept it unless you know the recipient is valid") is hard to apply. So I would suggest:

- Check the SPF.
- If the SPF is neutral, do some basic spam filtering, e.g. greylisting or RBLs. Probably not content-based unless they have plenty of CPU cycles to burn.

If the SPF or the spam-filter passes the message, accept it. If it ultimately can't be delivered, send an NDR.

If the SPF or the spam-filter reject the message, still accept it and attempt delivery (after all, the end user isn't asking for spam filtering at this point). However, in this case, if it ultimately can't be delivered then discard it.

I reckon that this would keep everyone happy, and wouldn't be hard to implement.

From a simpleton ... (0)

Anonymous Coward | more than 7 years ago | (#20349125)

I haven't looked at email as reliable for years, because of all of the games being played with it.

I'm not sure who's worse: the spammers or the anti-spam facists. Sure the spammers aren't doing anyone but themselves a favour, but the anti-spam facists seem to believe that technical tacticts are an effective way to solve a social problem. Unfortunately, they only seem to be making things worse by creating a sort of arms race. So now rather than having 50 unique spams sent once, I get 10 unique spams sent 20 times over -- where each of those 20 tries use a slightly different approach to get through filters. Sure the spammers created the problem, but the actions of the anti-spam facists only made it worse.

If email is so reliable these days... (1)

kindbud (90044) | more than 7 years ago | (#20349531)

Then how come people are paying for a Backup MX service?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?