Ah, I misunderstood!
It was not your mailserver that was a victim, but your mail address got abused as reply-to address, is that correct? The result is now, that if the spammer sends an email to a non-existant email address, the target server bounces the mail to the ‘sender’ via reply-to, ie, you
What I understood initially, was: your (legitimate) emails got returned by your contact, because the mailserver of your contacts thought your server is spamming. That is not the case, is it?
So, the chain of events, I think, is:
- spammer sends wpk@yuno.host a spam mail, with gilles as sender / reply-to
- mailserver at yuno.host does not know address wpk, and sends a helpful bounce message to the sender
- gilles receives the bounced message, with in the headers some of the trajectory the email has followed
The onus of recognizing the spam lies with the mailserver at 2) yuno.host, in this example.
I think there are only workarounds, not real solutions (as with everything spam, actually):
- work with whitelisting, and only allow email from your contacts. This is not a workable workaround if you got more than 20 acquaintances and sometimes meet new people;
- change your email address, and let your contacts know. And hope it does not end up in some nefarious scheme as well. Quite not nice, but workable.
- it is possible to discard bounce messages, or send them to another recipient. For this to work:
- the flood you receive has to be all (or mostly) bounce mails
- legitimate bounce mails will go undetected (if you send me an email with an error in the address, for example)
- it takes some puzzling with the Postfix configuration
The last option might be most promising. I know of the possibility, but not the syntax or the exact changes to make.
Stackoverflow has something in the right direction, the answer by Aaron:
Discarding Bounces:
In /etc/postfix/main.cfg, I have:
2bounce_notice_recipient = devnull
bounce_notice_recipient = devnull
bounce_queue_lifetime = 0d
delay_warning_time = 0h
alias_maps = hash:/etc/postfix/aliases
alias_database = hash:/etc/postfix/aliases
In /etc/postfix/aliases, I have:
devnull: /dev/null
Then I run:
postmap aliases
postfix reload
The end result is that bounces go to /dev/null. It may not catch all of them, so YMMV.
The postfix documentation mentions in relation to these bounce_notice_recipient that it will send an additional copy to the listed address (devnull in the example). If that is the case, this configuration will not help you.
All in all, a nasty problem 
If you decide to create a new emailaddress: for myself I have somewhat of an elaborate scheme to prevent the problem from having big consequences. Maybe it can serve as inspiration (or as an example of something you certainly don’t want to do 
)
- the email address itself / mailbox is not used publicly (no one sends to this address)
- I only receive emails on alias addresses for the mailbox
- I create a new alias per organization/contact/…
It takes some trouble each time I need to give an email address in a hurry, but so far I managed. The reason for only using aliases is that I can discard them without losing the mailbox. If there is a breach at a company/contact/…, and I receive spam on a specific address, I know there was a breach there. I can notify them of the breach, and change my mail address for that contact. After deleting the alias that was used previously, no spam is delivered anymore (but the so called sender of the spam will receive a bounce message…)
I’m out of fantasy/suggestions for the moment. Sorry for the long text. Maybe another forum member has another suggestion.
Please follow up and let us know in case you changed something and had, or had not, success!
