Interpret /var/spool/mqueue entries

[Matthew Seaman]

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 at 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 at distinction
> 09V2c6st082929     9067 Fri Oct 30 21:38 MAILER-DAEMON
>                   (Deferred: Connection refused by mail.enlighteneduponhearing.)
>                                           <besthealth-rates-me=example.com at enlig
> 09UNHHsv062419     2449 Fri Oct 30 18:17 <kn95_masks-me=example.com at distinctions
>            7BIT   (Deferred: 421-4.7.0 [107.161.21.234      15] Our system has )
>                                           <me at example.com>
> 09UMHcc1059037     5901 Fri Oct 30 17:17 <besthealth-rates-me=example.com at enligh
>            7BIT   (Deferred)
>                                           <me at 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.