"Bounce" to Spamcop spamtrap

[paulp]

Hello,

our domain 195.144.83.8 has been listed in bl.spamcop.net (127.0.0.2). I wrote to the deputies in order to find out what has happened and they sent me a copy of the offending mail. This helped me to search the logs and find what has happened:

A spammer, using a Spamcop spamtrap address as a fake sender address, sends 10 mails to our domain. 7 of them are sent to non existing addresses and they are refused immediately, without a bounce message. 3 of them are sent to legitimate addresses and are delivered. One of these three users has installed a forwarding to his home address. When the spam mail reaches the mail server of his home address, this server refuses, and sends a 554 message with the text "Mail contains a URL listed on www.surbl.org" to my mail server 195.144.83.8. This mail server notifies the sender (= the spamtrap) of the non delivery, and our domain gets on the blacklist.

The Spamcop deputy does not want to delist us, because "this is accept-and-bounce and accept-and-bounce is bad".

Is this really an accept-and-bounce case? What do you do if a mail gets refused before delivery? The sender somehow has to know that his mail was refused.

Most practically it would be to notify the sender only if it is a known account, but in my mail server program (Mailtraq) I cannot find a way to do this.

Any thoughts? Thanks!

[dbiel]

Sorry I can't help you in how to fix the problem, but you might find the following Wiki link helpful in understanding why it is a problem. Bounce

[paulp]

Sorry I can't help you in how to fix the problem, but you might find the following Wiki link helpful in understanding why it is a problem. Bounce

Yes, that's precisely what happened here: The receiving Mail Transfer Agent returns an SMTP reject code to the sending MTA that the email was not accepted. The sending MTA creates a separate email to send to the originator,

[dbiel]

Yes, that's precisely what happened here: The receiving Mail Transfer Agent returns an SMTP reject code to the sending MTA that the email was not accepted. The sending MTA creates a separate email to send to the originator,

The Sending MTA needs to not create a new message but rather simply continue forwarding (returning) the SMTP reject code back to the IP address it orginally received the message from as found in the headers, not to the from or reply to addresses which are often forged and the source of your problem as far as getting listed. Sorry that I can not help you in how to do that.

[Farelf]

...The receiving Mail Transfer Agent returns an SMTP reject code to the sending MTA that the email was not accepted. The sending MTA creates a separate email to send to the originator,

You can't risk sending a 'new mail' bounce to an unknown email address. Some server admins hang out here from time to time, maybe one or more of them will comment further with some actual advice.

Meantime, I assume you also saw the SC referral to (Official) SpamCop FAQ

[agsteele]

The Sending MTA needs to not create a new message but rather simply continue forwarding (returning) the SMTP reject code back to the IP address it orginally received the message from as found in the headers, not to the from or reply to addresses which are often forged and the source of your problem as far as getting

As dbiel says, only go down the SMTP reject route.

The sending server will attempt to pass back the failure message but without identifying your server as the originator. What you are doing is, effectively, duplicating the error message. As you've discovered sending a bounce message is now deprecated.

Turn of the bounce message part and you will find yourself free of your listing in a short time.

Andrew

[paulp]

As dbiel says, only go down the SMTP reject route. Turn of the bounce message part and you will find yourself free of your listing in a short time.

Thanks for all you ideas. I'll have to find out how to turn off this thing, and the help forum of my MTA Mailtraq is rather silent at the moment ...

[StevenUnderwood]

The sender somehow has to know that his mail was refused.

That is not necessarily the case. Messages are dropped into Junk mail or Trash folders automatically all over the world and the sender has no way of knowing that. SMTP is NOT a guaranteed delivery process.

That forward should be a separate transaction, not linked to the original delivery. You have already accepted the message, you have already told the original sender it is deliverable. Your user is refusing the message YOUR system sent.

[Telarin]

The Sending MTA needs to not create a new message but rather simply continue forwarding (returning) the SMTP reject code back to the IP address it orginally received the message from as found in the headers, not to the from or reply to addresses which are often forged and the source of your problem as far as getting listed. Sorry that I can not help you in how to do that.

That is technically impossible. The MTA in the middle must fully receive the message from the original sending MTA before it forwards it on to the final destination MTA. I believe current best practice is to never generate NDR messages for mail that was forwarded, as the forwarding MTA has no way of knowing where to deliver the NDR.