Jump to content

Delayed bounces and UUCP batch mail sites?


Recommended Posts

We have been blacklisted recently because of delayed bonuces:

http://www.spamcop.net/bl.shtml?212.63.63.2

From what I can see from the description it may have been the majordomo program that we have been running (I turned the autoresponder off) or it could be the problem that this mail server the hub for quite a few UUCP connected sites. As I do not know the users that are behind an UUCP node I have no chance but to queue that mail and let the end node decide if the mail is valid. This will definitely generate delayed bounces and might get me blacklisted again. Does that mean that if you happen to still support batch mail systems like UUCP that you will always risk being blacklisted?

Unfortunatley the pages that one gets referred to do not divulge the real reason one gets blacklisted, so I am required to guess what might have been the reason.

Link to comment
Share on other sites

We have been blacklisted recently because of delayed bonuces:

http://www.spamcop.net/bl.shtml?212.63.63.2

In general, the only items 'defined' these days for being in the BL is based on spamtrap hits or user reports/complaints. The "delayed bounces" these days does tend to tie in with spammer abuse, and a BL listing wouldn't be due to the "delayed" situation, it would be the "misdirected" part of that problem.

Unfortunatley the pages that one gets referred to do not divulge the real reason one gets blacklisted, so I am required to guess what might have been the reason.

38731[/snapback]

Not sure what pages you might be referring to. The problem "right now" is that the IP isn't currently listed.

http://www.spamcop.net/w3m?action=blcheck&ip=212.63.63.2

212.63.63.2 not listed in bl.spamcop.net

http://www.senderbase.org/?searchBy=ipaddr...ing=212.63.63.2 still shows a listing, so would have to believe that the "unlisted" condition is still propogating. Though curious if the "turned off the autoresponder" is the only reason for the decreased traffic levels seen ftom that IP/server?

Another invitation to try the SpamCop FAQ here, to include the Why am I Blocked? entry.

Link to comment
Share on other sites

Not sure what pages you might be referring to.  The problem "right now" is that the IP isn't currently listed.

http://www.spamcop.net/w3m?action=blcheck&ip=212.63.63.2

212.63.63.2 not listed in bl.spamcop.net

Well, that is due to me using the option to delist the machine as I have received complaints from my users and I initially wanted to make sure that mail gets through.

http://www.senderbase.org/?searchBy=ipaddr...ing=212.63.63.2 still shows a listing, so would have to believe that the "unlisted" condition is still propogating.

Another invitation to try the SpamCop FAQ here, to include the Why am I Blocked? entry.

38733[/snapback]

I have read that FAQ and I do not have any of the mentioned mail systems in use (I use plain old sendmail on the mail hub and postfix on a secondary mx). I still have no clue as why my machines where blocked. I have not seen which way any misdirected bounces should have happened on my system. I only found one possible culprit (majordomo) and disabled that one.

As per the bounces, this is an ongoing old problem for our domain (han.de). We do mail since the dawn of the internet (started as UUCP node in the early days) and we do process thousends of bounces each day due to spammers using *[at]*.han.de adresses in their From: and Reply-To: mail headers. Apparently our domain is a popular one on several of the CD-ROM address lists. But I do not see any way of getting around this beyond giving up han.de, which is not an option.

Link to comment
Share on other sites

Well, that is due to me using the option to delist the machine as I have received complaints from my users and I initially wanted to make sure that mail gets through.

38734[/snapback]

Did you take notice of the message that if the problem has not been fixed, and you become listed again, that you will not have that option again.

I have read that FAQ and I do not have any of the mentioned mail systems in use (I use plain old sendmail on the mail hub and postfix on a secondary mx).

38734[/snapback]

I don't know what you read, but the entry Wazoo is referring to does not mention any mail systems by name. The version he was referring to is: Why Am I Blocked?

I still have no clue as why my machines where blocked. I have not seen which way any misdirected bounces should have happened on my system. I only found one possible culprit (majordomo) and disabled that one.

38734[/snapback]

To get any possible information about the spamtrap hit, you will need to contact deputies[at]spamcop.net.

From your original message:

As I do not know the users that are behind an UUCP node I have no chance but to queue that mail and let the end node decide if the mail is valid. This will definitely generate delayed bounces and might get me blacklisted again. Does that mean that if you happen to still support batch mail systems like UUCP that you will always risk being blacklisted?
If you can not verify the end user account is willing and able to receive the message at the time of acceptance at your system, you should turn off sending "delayed biounces" for those systems and simply delete the message. If your system is sending the "delayed bounce" back to a forged address that happens to be a spamtrap, you will get listed. If your system is sending the "delayed bounce" back to a forged address that happens to be a person using spamcop to report spam, you will get listed.

As per the bounces, this is an ongoing old problem for our domain (han.de). We do mail since the dawn of the internet (started as UUCP node in the early days) and we do process thousends of bounces each day due to spammers using *[at]*.han.de adresses in their From: and Reply-To: mail headers. Apparently our domain is a popular one on several of the CD-ROM address lists. But I do not see any way of getting around this beyond giving up han.de, which is not an option.

38734[/snapback]

Receiving of misdirected bounces is NOT the problem here, but is your view of what you are doing to others by using "delayed bounces".
Link to comment
Share on other sites

Contacting the Deputies would definitely be appropriate in this case, as would filtering outgoing bounces and asking your UUCP connected spokes to stop sending bounces to your hub.

Link to comment
Share on other sites

Did you take notice of the message that if the problem has not been fixed, and you become listed again, that you will not have that option again.

I know that and I did it on purpose. I wanted to be able to send mail while I evalute the situation and find my options.

From your original message:  If you can not verify the end user account is willing and able to receive the message at the time of acceptance at your system, you should turn off sending "delayed biounces" for those systems and simply delete the message.  If your system is sending the "delayed bounce" back to a forged address that happens to be a spamtrap, you will get listed.  If your system is sending the "delayed bounce" back to a forged address that happens to be a person using spamcop to report spam, you will get listed.

Receiving of misdirected bounces is NOT the problem here, but is your view of what you are doing to others by using "delayed bounces".

38735[/snapback]

Most connected sites consider it to be an intrusion into their local sysadmin issues and thus do not support the idea of white lists. These are not all single user sites, may are multi-user and do not want to divulge the list of accounts they have. I am trying this for some years now and I did not succeed to convince the club members.

And as per the bounces - they are timely. It appears to be just not your sense of timely. We have been discussing about when unreacheable bounces are supposed to be sent, and most UUCP sites considered 7 days to be the minimum time frame. Similar times were mentioned for other bounces.

I would suspect that upon voting most of the connected sites would probably not give up their current way of doing things, even if it is causing a listing in SpamCop. But then I am not authorized to decide this issue.

Link to comment
Share on other sites

Most connected sites consider it to be an intrusion into their local sysadmin issues and thus do not support the idea of white lists. These are not all single user sites, may are multi-user and do not want to divulge the list of accounts they have. I am trying this for some years now and I did not succeed to convince the club members.

38773[/snapback]

There are other ways but without having access to what addresses are valid, it is best to simply delete any non-deliverable messages.

And as per the bounces - they are timely. It appears to be just not your sense of timely. We have been discussing about when unreacheable bounces are supposed to be sent, and most UUCP sites considered 7 days to be the minimum time frame. Similar times were mentioned for other bounces.

38773[/snapback]

It is not the timing of the bounces but the fact they are going to incorrect addresses. Unless you can verify that the from address is where the message actually came from, it is best not to send them. Same with Out of Office replies and other types of automatic replies.

I would suspect that upon voting most of the connected sites would probably not give up their current way of doing things, even if it is causing a listing in SpamCop. But then I am not authorized to decide this issue.

38773[/snapback]

That is your/their choice as it is ours to report bounce messages we did not originally send and to block systems that send such messages.
Link to comment
Share on other sites

I would suspect that upon voting most of the connected sites would probably not give up their current way of doing things, even if it is causing a listing in SpamCop. But then I am not authorized to decide this issue.

If they were receiving hundreds of emails stating that email was undeliverable that they never sent, they might change their minds.

As Steven Underwood said, it is your choice. Those who do receive backscatter will use blocklists and ask correspondents to find another way to contact them.

The internet is built on netiquette. There is nothing rude in 'not being in' to intrusive email. There is a lot of selfishness in demanding that everyone accept one's email in spite of the fact that in order to do so, the recipient has dozens, hundreds, or even thousands of unsolicited, unwanted email to deal with.

But it is your choice.

Miss Betsy

Link to comment
Share on other sites

Is there any way you can isolate the nodes that want to send bounces from the rest of your system and the cooperating nodes, such that the nodes that want to send bounces send those using a separate (eventually relisted) IP Address? Thanks!

Link to comment
Share on other sites

There are other ways but without having access to what addresses are valid, it is best to simply delete any non-deliverable messages.

I understand that one, and it is easy to do from the internet gateway side of the UUCP network. That means, If I cannot deliver, I can delete the remnants after some time.

It is not the timing of the bounces but the fact they are going to incorrect addresses.  Unless you can verify that the from address is where the message actually came from, it is best not to send them.  Same with Out of Office replies and other types of automatic replies.

Well the problem appears to be here that UUCP still believes in the envelope adresses as noted by the internet MTA. If I understand you right that also means that secondary MX hosts have to check the destination adresses before buffering a mail for later delivery? I understand that quite a few sites have some secondary MX agreements without necessarly validating each and every mail, delivering bounces later after the primary is back up.

Is there any way you can isolate the nodes that want to send bounces from the rest of your system and the cooperating nodes, such that the nodes that want to send bounces send those using a separate (eventually relisted) IP Address?  Thanks!

38779[/snapback]

These systems do not even have IP adresses, we are talking dialup batch UUCP networking here, there is not even a phone number noted if caller ID is disabled.

Is there any way you can isolate the nodes that want to send bounces from the rest of your system and the cooperating nodes, such that the nodes that want to send bounces send those using a separate (eventually relisted) IP Address?  Thanks!

38779[/snapback]

Oh, wait. I misunderstood in my first reply. Yes, we use two outgoing SMTP servers, one for normal POP/IMAP users and one for the UUCP machines. Only the one for the UUCP machines appeared on your list.

If they were receiving hundreds of emails stating that email was undeliverable that they never sent, they might change their minds.

Well, been there and did already fight that. We have had very huge spews of bounces delivered to us and we did filter it out. Hundreds is peanuts on what we did receive at times. If I remember right at unabomber times we did get above 60000 per account per day. Not that I did like it, but at least we did work with the worst offenders and showed them what exactly did happen did not let them guess.

As Steven Underwood said, it is your choice.  Those who do receive backscatter will use blocklists and ask correspondents to find another way to contact them.

The internet is built on netiquette.  There is nothing rude in 'not being in' to intrusive email.  There is a lot of selfishness in demanding that everyone accept one's email in spite of the fact that in order to do so, the recipient has dozens, hundreds, or even thousands of unsolicited, unwanted email to deal with.

Yes, and we did do send the original Miss Betsy articles to our new users to educate them in mail and usenet etiquette. But we have not done so for quite a while, probably because we did not have many new users in recent times.

As far as I am concerned I am mostly upset about not being able to exactly diagnose why the whole shebang is happening. Even our UUCP sites should be sending proper bounces, although not necessarily timely. Wasn't the original Internet a place where debugging ones networking problems was considered an excercise in collaboration?

Link to comment
Share on other sites

Well the problem appears to be here that UUCP still believes in the envelope adresses as noted by the internet MTA. If I understand you right that also means that secondary MX hosts have to check the destination adresses before buffering a mail for later delivery? I understand that quite a few sites have some secondary MX agreements without necessarly validating each and every mail, delivering bounces later after the primary is back up.

38780[/snapback]

Nobody has to check anything before accepting the messages. BUT after accepting and finding a message non-deliverable, DO NOT send to the (often) forged envelope sender.

Wasn't the original Internet a place where debugging ones networking problems was considered an excercise in collaboration?

38780[/snapback]

Things have changed immensely since that time. Spammers have ruined the "trust" that was the SMTP system for so long.
Link to comment
Share on other sites

Well, been there and did already fight that. We have had very huge spews of bounces delivered to us and we did filter it out. Hundreds is peanuts on what we did receive at times. If I remember right at unabomber times we did get above 60000 per account per day. Not that I did like it, but at least we did work with the worst offenders and showed them what exactly did happen did not let them guess.

The problem is again the spammers. The spammers looked at the reports and used them to fool the parser. Please email deputies <at> spamcop.net. They will work with you.

We are sorry that we can't help more here, but we can't see what is happening either.

Miss Betsy

PS I am glad that you find my FAQ useful for your users! Thanks for mentioning it.

Link to comment
Share on other sites

As far as I am concerned I am mostly upset about not being able to exactly diagnose why the whole shebang is happening. Even our UUCP sites should be sending proper bounces, although not necessarily timely. Wasn't the original Internet a place where debugging ones networking problems was considered an excercise in collaboration?

38780[/snapback]

Please write to the email address in my sig and we can discuss what is happening.

Link to comment
Share on other sites

As far as I am concerned I am mostly upset about not being able to exactly diagnose why the whole shebang is happening. Even our UUCP sites should be sending proper bounces, although not necessarily timely.

The problem is that ANY time after the SMTP transaction, when it should be rejected witha 5** code is now 'untimely'. Once you accept it you should never, at any time, bounce to the return envelope: it's as simple as that.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...