Date: Sat, 31 Oct 2020 20:00:57 +0000 From: Matthew Seaman <matthew@FreeBSD.org> To: freebsd-questions@freebsd.org Subject: Re: Interpret /var/spool/mqueue entries Message-ID: <203e817c-4c14-42aa-d7fe-36ac0cf5460e@FreeBSD.org> In-Reply-To: <202010311321.09VDLS9u007248@belics.com> References: <202010311321.09VDLS9u007248@belics.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 31/10/2020 13:21, Rob Belics wrote: > I thought this was a solved problem in my sendmail configuration but, over the last few days, I've gotten some entries and I've forgotten how to interpret them. To me, it appears that the first two entries show that I'm relaying some mail and it was refused by the receiver. But I'm wondering if someone is impersonating my email address and that is why I'm getting a bounce back. > > Is that right? What should I check in sendmail configuration? Note that I changed my email in the examples below to me@example.com > > Mail in local queue: > /var/spool/mqueue (4 requests) > -----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient----------- > 09V3c6st046407 5478 Fri Oct 30 22:38 MAILER-DAEMON > (Deferred: Connection refused by mail.distinctionspots.com.) > <kn95_masks-me=example.com@distinction > 09V2c6st082929 9067 Fri Oct 30 21:38 MAILER-DAEMON > (Deferred: Connection refused by mail.enlighteneduponhearing.) > <besthealth-rates-me=example.com@enlig > 09UNHHsv062419 2449 Fri Oct 30 18:17 <kn95_masks-me=example.com@distinctions > 7BIT (Deferred: 421-4.7.0 [107.161.21.234 15] Our system has ) > <me@example.com> > 09UMHcc1059037 5901 Fri Oct 30 17:17 <besthealth-rates-me=example.com@enligh > 7BIT (Deferred) > <me@example.com> This looks to me to be spam e-mail that your mail filters have rejected, resulting in your mail system trying to bounce the message back to the sender. However, it seems that the sender isn't accepting any bounce messages, probably because the headers in the original spam were forged. Note that bouncing a spam message like this can be a bad thing: some spammers deliberately send messages that will be bounced, but they put the _real_ targetted victim address into the Sender headers, so their spam message gets reflected from some innocent, but real, mail system thus avoiding various blacklists or reputation scoring tests. It's called "backscatter" spam. The way to avoid this is to configure your mail system and spam filters so that either: * Spam messages are rejected in the middle of the SMTP dialogue, before receipt has been acknowledged. Since receipt has not been acknowledged, the message is still technically the responsibility of the sending system, which should ultimately result in the admins of that system getting bounce-o-grammes and (just possibly) getting clued into the fact that their system is being used to pump out spam and hence fix it.[*] * After receipt, any message determined to be spam is either deleted or quarantined but _not_ bounced back to the sender Cheers, Matthew [*] Actually, spam mail injection frequently comes from compromised desktop systems running some malware without a fully capable SMTP server being involved, in which case, they usually work by replaying a pre-recorded SMTP dialogue and simply can't cope with getting a rejection.[**] [**] Another neat trick here is to add a small delay before your server emits its initial greeting message. Real SMTP servers will wait until you have emitted your greeting. Spam bots frequently will not, and if anything has the temerity to speak out of turn, you can just bounce the message straight away. It's a very cheap but pretty effective filtering mechanism.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?203e817c-4c14-42aa-d7fe-36ac0cf5460e>