Jump to content

bounce question


Mike D

Recommended Posts

My Exchange 5.5 server (216.18.74.201) has been recently listed twice in the past few days for misdirected bounces. I installed the MS hotfix from KB 837794 and set the registry option to 100. After being relisted I set it to 10.

My first question is why was I never listed sooner? I've seen (presumably) bogus NDRs piling up in the IMC outbound queue for months and never had any problems. Is it something new on my side I need to investigate or Spamcop just never tested me before?

Second, shouldn't it be sufficient to stop delivery of NDRs to missing return addresses (option 100). Do I need to actually prevent generation of ALL NDRs (option 10) so even legitimate senders aren't advised of typos, etc.? Am I misunderstanding these registry values?

Thanks for any help,

Mike

Link to comment
Share on other sites

Possible typo in the IP offered?

http://www.senderbase.org/?searchBy=ipaddr...g=216.18.74.201

Date of first message seen from this address = blank

Volume Statistics for this IP

Magnitude Vol Change vs. Average

Last day ........ 0.0 .. -100%

Last 30 days .. 0.0 .. -100%

Average ........ 0.0

SpamCop Blocking List Service

SpamCop doesn't "test" e-mail servers ... only reacting to submitted complaints or spamtrap hits.

Single-Page entry point for the SpamCop FAQ

http://www.senderbase.org/?sb=1&searchBy=i...g=216.18.74.161 looks like this was listed, possibly in the process of being de-listed

Link to comment
Share on other sites

So we are on the same page, I am looking at article Update available in Exchange Server 5.5 to control whether the Internet Mail Service suppresses or delivers NDRs.

That article recommends installing its associated hotfix (which one currently has to get via personal contact with Microsoft Product Support Services) and adding a "SuppressNDROptions" "DWORD Value" to subkey "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIMC\Parameters".

The appropriate "Value data" (in hexadecimal, per step #6) for being a good network neighbor, netizen, and corporate citizen is "10", which means "To enable this feature so that the Internet Mail Service does not generate NDRs". Even if your mailserver doesn't generate NDRs, you probably still want it to deliver those generated by others. Your users may not be ready for "Value data" "1", which appears to filter out ALL NDRs.

The "Value data" you originally selected, "100", only eliminates double-bounces (NDRs for NDRs) ending up in the administrator's mailbox (allowing the administrator to put its head in the sand), it doesn't help the rest of the Internet one whit.

If Exchange Server 5.5 could reject mail at the SMTP level (with 500-series errors), or was fronted with a bastion host that could do that, such a situation would keep its NDRs off the Internet, and it could still generate NDRs internally with "Value data" of "100" or preferably "0".

Link to comment
Share on other sites

Thanks guys,

Yes, Wazoo, it was a typo should have been 216.18.74.161

Thanks for the links. I guess I won't be able to avoid all that reading after all.

Jeff, thanks for the clarification. I was confused about the difference between "1" and "10" was since I thought "1" only referred to NDRs that were generated by the Internet Mail Service.

You say that I should use "10" to be "a good network neighbor, netizen, and corporate citizen" but I am concerned that clients and customers will believe their misaddressed emails were received, and will be acted upon, because they never received notification to the contrary.

Management won't accept our emails being blocklisted or customer's emails getting "lost". Is there no simpler solution for this sudden situation than installing a new gateway box?

Link to comment
Share on other sites

My first question is why was I never listed sooner? I've seen (presumably) bogus NDRs piling up in the IMC outbound queue for months and never had any problems. Is it something new on my side I need to investigate or Spamcop just never tested me before?

Second, shouldn't it be sufficient to stop delivery of NDRs to missing return addresses (option 100). Do I need to actually prevent generation of ALL NDRs (option 10) so even legitimate senders aren't advised of typos, etc.? Am I misunderstanding these registry values?

Thanks for any help,

Mike

31080[/snapback]

First: It is possible that one (or more) of your NDR's was returned to a valid email address that just happens to be a spamcop spamtrap address, placed into the messages by a spammer or virus. It is not the ones that your box can not deliver that are causing you problems but the ones it can deliver.

Second: Because of the answer to the first, no that is not sufficient. You are not only returning bounces to people who have mis-typed an address, you are returning bounces to innocent third parties who have had their valid addresses forged into the return address or from field.

As Jeff G. stated, rejecting during the SMTP process is the only safe way to generate NDR's at this point in time.

Link to comment
Share on other sites

<snip>

Management won't accept our emails being blocklisted or customer's emails getting "lost".

<snip>

31091[/snapback]

...That's a bit like their not accepting a solar eclipse -- they have no choice :) <g>. E-mail is not a guaranteed-delivery mechanism.
Link to comment
Share on other sites

...That's a bit like their not accepting a solar eclipse -- they have no choice :) <g>.  E-mail is not a guaranteed-delivery mechanism.

31102[/snapback]

He does have another choice and instead of sending emails to senders of non-deliverable addresses, he can have them go to a special place and review them for 'mistyped' addresses which he can manually email (or pass on to the correct address with a note to notify sender that address is incorrect).

Miss Betsy

Link to comment
Share on other sites

...That's a bit like their not accepting a solar eclipse -- they have no choice :) <g>.  E-mail is not a guaranteed-delivery mechanism.

31102[/snapback]

He does have another choice and instead of sending emails to senders of non-deliverable addresses, he can have them go to a special place and review them for 'mistyped' addresses which he can manually email (or pass on to the correct address with a note to notify sender that address is incorrect).

Miss Betsy

31111[/snapback]

...As usual, you add an excellent idea to the conversation. However that isn't what my post was about -- I was referring to your point which I often paraphrase that backhoes sometimes cut lines, etc. That is, a customer's e-mail might not even make it to Mike D's server but be lost somewhere on the internet.
Link to comment
Share on other sites

He does have another choice and instead of sending emails to senders of non-deliverable addresses, he can have them go to a special place and review them for 'mistyped' addresses which he can manually email (or pass on to the correct address with a note to notify sender that address is incorrect).

Miss Betsy

31111[/snapback]

...As usual, you add an excellent idea to the conversation. However that isn't what my post was about -- I was referring to your point which I often paraphrase that backhoes sometimes cut lines, etc. That is, a customer's e-mail might not even make it to Mike D's server but be lost somewhere on the internet.

31113[/snapback]

Yes, I know what you were referring to, but yours was the post closest to replying to the idea that 'management doesn't want to be blocked and also doesn't want to lose email' - the caveat being that email will get lost no matter what one does. However, he can hedge against losing an email due to it being mistyped without spamming others by replying to forged return paths. Like him, I was just too lazy to find the quote I was referring to and the results were somewhat similar - confusion.

Miss Betsy

EDIT: Believe I fixed the quoting and killed extra white space - Wazoo

EDIT: I finished the "killing extra white space" job. - Jeff G.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...