From owner-freebsd-questions@freebsd.org Sat Oct 31 20:01:00 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 82593454CAF for ; Sat, 31 Oct 2020 20:01:00 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CNqmr2wwPz3ctK for ; Sat, 31 Oct 2020 20:01:00 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [81.2.117.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "Let's Encrypt Authority X3" (verified OK)) (Authenticated sender: matthew/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 24E0A1C34F for ; Sat, 31 Oct 2020 20:01:00 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from PD0786.local (130.31-255-62.static.virginmediabusiness.co.uk [62.255.31.130]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id 531311CAC0 for ; Sat, 31 Oct 2020 20:00:58 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: smtp.infracaninophile.co.uk/531311CAC0; dkim=none; dkim-atps=neutral From: Matthew Seaman Subject: Re: Interpret /var/spool/mqueue entries To: freebsd-questions@freebsd.org References: <202010311321.09VDLS9u007248@belics.com> Message-ID: <203e817c-4c14-42aa-d7fe-36ac0cf5460e@FreeBSD.org> Date: Sat, 31 Oct 2020 20:00:57 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <202010311321.09VDLS9u007248@belics.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2020 20:01:00 -0000 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.) > 09V2c6st082929 9067 Fri Oct 30 21:38 MAILER-DAEMON > (Deferred: Connection refused by mail.enlighteneduponhearing.) > 09UNHHsv062419 2449 Fri Oct 30 18:17 7BIT (Deferred: 421-4.7.0 [107.161.21.234 15] Our system has ) > > 09UMHcc1059037 5901 Fri Oct 30 17:17 7BIT (Deferred) > 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.