Turning off DSN on sendmail to prevent backscatter
I sent that?
One morning, I got a bounce message from my own mail sendmail server, saying that it failed to deliver a message I never sent. That’s red alert. It means that someone managed to provoke my mail server to send an outbound message. It’s red alert, because my mail server effectively relays spam to any destination that the spammer chooses. This could ruin the server’s reputation horribly.
It turned out that an arriving mail required a return receipt, which was destined to just some mail address. There’s an SMTP feature called Delivery Status Notification (DSN), which allows the client connecting to the mail server to ask for a mail “in return”, informing the sender of the mail if it was properly delivered. The problem is that the MAIL FROM / From addresses could be spoofed, pointing at a destination to spam. Congratulations, your mail server was just tricked into sending spam. This kind of trickery is called backscatter.
Checking my own mail logs, the DSN is a virtually unused feature. So it’s probably just something spammers can take advantage of.
The relevant RFC for DSN is RFC1891. Further explanations on DSN can be found in one of sendmail’s tutorial pages.
How to turn DSN off
First, I recommend checking if it’s not disabled already, as explained below. In particular, if the paranoid-level “goaway” privacy option is used, DSN is turned off anyhow.
It’s actually easy. Add the noreceipts option to PrivacyOptions. More precisely, edit /etc/mail/sendmail.mc and add noreceipts to the list of already existing options. In my case, it ended up as
define(`confPRIVACY_FLAGS',dnl
`needmailhelo,needexpnhelo,needvrfyhelo,restrictqrun,restrictexpand,nobodyreturn,noetrn,noexpn,novrfy,noactualrecipient,noreceipts')dnl
and then run “make” in /etc/mail, and restart sendmail.
Turning off DSN is often recommended against in different sendmail guides, because it’s considered a “valuable feature” or so. As mentioned above, I haven’t seen it used by anyone else than spammers.
Will my mail server do DSN?
Easy to check, because the server announces its willingness to fulfill DSN requests at the beginning of the SMTP session, with the line marked in red in the sample session below:
<<< 220 mx.mymailserver.com ESMTP MTA; Wed, 15 Jul 2020 10:22:32 GMT
>>> EHLO localhost.localdomain
<<< 250-mx.mymailserver.com Hello 46-117-33-227.bb.netvision.net.il [46.117.33.227], pleased to meet you
<<< 250-ENHANCEDSTATUSCODES
<<< 250-PIPELINING
<<< 250-8BITMIME
<<< 250-SIZE
<<< 250-DSN
<<< 250-DELIVERBY
<<< 250 HELP
>>> MAIL FROM:<spamvictim@billauer.co.il>
<<< 250 2.1.0 <spamvictim@billauer.co.il>... Sender ok
>>> RCPT TO:<legal_address@billauer.co.il> NOTIFY=SUCCESS
<<< 250 2.1.5 <legal_address@billauer.co.il>... Recipient ok
>>> DATA
<<< 354 Enter mail, end with "." on a line by itself
>>> MIME-Version: 1.0
>>> From: spamvictim@billauer.co.il
>>> To: legal_address@billauer.co.il
>>> Subject: Testing email.
>>>
>>>
>>> Just a test, please ignore
>>> .
<<< 250 2.0.0 06FAMWa1014200 Message accepted for delivery
>>> QUIT
<<< 221 2.0.0 mx.mymailserver.com closing connection
To test a mail server for its behavior with DSN, the script that I’ve already published can be used. To make it request a return receipt, the two lines that set the SMTP recipient should be changed to
die("Failed to set receipient\n")
if (! ($smtp->recipient( ($to_addr ), { Notify => ['SUCCESS'] } ) ) );
This change causes the NOTIFY=SUCCESS part in the RCPT TO line, which effectively requests a receipt from the server when the mail is properly delivered.
Note that if DSN isn’t supported by the mail server (possibly because of the privacy option fix shown above), the SMPT session looks exactly the same, except that the SMTP line marked in red will be absent. Then the mail server just ignores the NOTIFY=SUCCESS part silently, and responds exactly as before.
However when running the Perl script, the Net::SMTP will be kind enough to issue a warning to its stderr:
Net::SMTP::recipient: DSN option not supported by host at ./testmail.pl line 36.
The mail addresses I used in the sample session above are bogus, of courses, but note that the spam victim is the sender of the email, because that’s where the return receipt goes. On top of that, the RCPT TO address will also get a spam message, but that’s the smaller problem, as it’s yet another spam message arriving — not one that is sent away from our server.
I should also mention that Notify can be a comma-separated list of events, e.g.
RCPT TO:<bad_address@billauer.co.il> NOTIFY=SUCCESS,FAILURE,DELAY
however FAILURE doesn’t include the user not being known to the server, in which case the message is dropped anyhow without any DSN message generated. So as a spam trick, one can’t send mails to random addresses, and issue spam bounce messages because they failed. That would have been too easy.
In the mail logs
The sample session shown above causes the following lines in mail.log. Note the line marked in red, which indicates that the return receipt mechanism was fired off.
Jul 15 10:15:31 sm-mta[12697]: 06FAFTbL012697: from=<spamvictim@billauer.co.il>, size=121, class=0, nrcpts=1, msgid=<202007151015.06FAFTbL012697@mx.mymailserver.com>, proto=ESMTP, daemon=IPv4-port-587, relay=46-117-33-227.bb.netvision.net.il
[46.117.33.227]
Jul 15 10:15:31 sm-mta[12698]: 06FAFTbL012697: to=<legal_address@billauer.co.il>, ctladdr=<spamvictim@billauer.co.il> (1010/500), delay=00:00:01, xdelay=00:00:00, mailer=local, pri=30456, dsn=2.0.0, stat=Sent
Jul 15 10:15:31 sm-mta[12698]: 06FAFTbL012697: 06FAFVbL012698: DSN: Return receipt
Jul 15 10:15:31 sm-mta[12698]: 06FAFVbL012698: to=<spamvictim@billauer.co.il>, delay=00:00:00, xdelay=00:00:00, mailer=local, pri=30000, dsn=2.0.0, stat=Sent
The receipt
Since I’m at it, this is what a receipt message for the sample session above looks like:
Received: from localhost (localhost) by mx.mymailserver.com (8.14.4/8.14.4/Debian-8+deb8u2) id 06FAFVbL012698; Wed, 15 Jul 2020 10:15:31 GMT Date: Wed, 15 Jul 2020 10:15:31 GMT From: Mail Delivery Subsystem <MAILER-DAEMON@billauer.co.il> Message-ID: <202007151015.06FAFVbL012698@mx.mymailserver.com> To: <spamvictim@billauer.co.il> MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="06FAFVbL012698.1594808131/mx.mymailserver.com" Subject: Return receipt Auto-Submitted: auto-generated (return-receipt) X-Mail-Filter: main This is a MIME-encapsulated message --06FAFVbL012698.1594808131/mx.mymailserver.com The original message was received at Wed, 15 Jul 2020 10:15:30 GMT from 46-117-33-227.bb.netvision.net.il [46.117.33.227] ----- The following addresses had successful delivery notifications ----- <legal_address@billauer.co.il> (successfully delivered to mailbox) ----- Transcript of session follows ----- <legal_address@billauer.co.il>... Successfully delivered --06FAFVbL012698.1594808131/mx.mymailserver.com Content-Type: message/delivery-status Reporting-MTA: dns; mx.mymailserver.com Received-From-MTA: DNS; 46-117-33-227.bb.netvision.net.il Arrival-Date: Wed, 15 Jul 2020 10:15:30 GMT Final-Recipient: RFC822; legal_address@billauer.co.il Action: delivered (to mailbox) Status: 2.1.5 Last-Attempt-Date: Wed, 15 Jul 2020 10:15:31 GMT --06FAFVbL012698.1594808131/mx.mymailserver.com Content-Type: text/rfc822-headers Return-Path: <spamvictim@billauer.co.il> Received: from localhost.localdomain (46-117-33-227.bb.netvision.net.il [46.117.33.227]) by mx.mymailserver.com (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id 06FAFTbL012697 for <legal_address@billauer.co.il>; Wed, 15 Jul 2020 10:15:30 GMT Date: Wed, 15 Jul 2020 10:15:29 GMT Message-Id: <202007151015.06FAFTbL012697@mx.mymailserver.com> MIME-Version: 1.0 From: spamvictim@billauer.co.il To: legal_address@billauer.co.il Subject: Testing email. --06FAFVbL012698.1594808131/mx.mymailserver.com--
But note that if DSN is used by a spammer to trick our mail server, we will get the failure notice that results from sending this message to the other server. If we’re lucky enough to get anything at all: If the message is accepted, we’ll never know our server has been sending spam.
Reader Comments
Thanks. I feel more confident in turning this off. I’ve had a few “postmaster notify” emails from my server resulting from return-receipt requests in spam that targets an invalid address.
But, like you said, what else is being generated that I don’t see.
My server is also responding to
Disposition-Notification-To: Noreply@clifford.ac
in spam.
This is a potential source of backscatter too so I would like to prevent this.
What server is that? This post is about sendmail. As far as I know, sendmail doesn’t process Disposition-Notification-To.
It is sendmail. There is no reason for sendmail to send this to Noreply@clifford.ac
Date: Sat, 19 Feb 2022 05:46:12 GMT
From: Mail Delivery Subsystem
To: Noreply@clifford.ac
Subject: Return receipt
Maybe I’ve been mislead by the Disposition-Notification-To in the original and the different format of the message. But, thinking about it, one was because of an unsuccessful delivery and this one was for a successful delivery. The subject says “Return receipt” though so they must have asked for the return receipt as well. I was just assuming the “Subject: Return receipt” was a generic header.
I found this:
Note that this also causes the ESMTP DSN feature to not be advertised in the EHLO response. But, because that feature is very valuable, we recommend you not specify noreceipts.
on etutorial.org about “noreceipts” but there is no explanation of “very valuable”
“Very valuable” is in the eyes of the beholder, I guess.
The question is: Is it still possible to provoke sendmail into sending an email after adding the noreceipts option?
I’m not understanding something about this. A spam caused my server to send a return receipt. This was unsuccessful so my server sent me a notify: http://clifford.ac/photo/temp/return-receipt_unroutable.txt
I cannot find anything in the headers of the original spam that shows a request for a return receipt: http://clifford.ac/photo/temp/original_spam.txt
Neither I could find anything to provoke a return receipt in that spam mail. Maybe sendmail chopped off the relevant header…?
Or even worse, maybe sendmail sends a return receipt to all arriving mails because of some weird configuration?
Most interesting: What does the mail log say about this mail exchange? Sending the return receipt should be logged there, possibly with an explanation on why.
And that should also answer the question if all mails get a receipt.
Relevant bit of the mail log: http://clifford.ac/photo/temp/maillog.txt
A grep of the mail log returns only one return receipt but there have been a few in the previous log.
http://clifford.ac/photo/temp/returnreceiptgrep.txt
http://clifford.ac/photo/temp/returnreceiptgrep_1.txt
I’ll have a look at the originals emails of those others.
I’ve set up alpine with a gmail account so I can put in headers. I’ll do some testing of my server but I won’t be able to replicate the false envelope “from ” that the spam had (if that was important).
I have progressed. I put “-N success” in a command line sendmail on my macbook and my server at home generated a return receipt. There is nothing in the header of the email I sent requesting it.
So I’ll try switching off dsn on my server and try again. (I have to proceed carefully because I’m a few thousand kilometres from home at the moment!)
I just tried contacting your mail server with the script on this page:
https://billauer.co.il/blog/2013/01/perl-sendmail-exim-postfix-test/
And guess what, the 250 DSN line was present in its response. The reason your server sends receipts is well, because you didn’t disable that option.
I’ve implememented “noreceipts” in my mailservers. Interesting that I could request a receipt with the sendmail command line option “-N” rather than in the email header.
To me this looks like some trivial issue: Wrong configuration file, the setting overridden somewhere else, or something like that.
Me too: included `noreceipts’ as an additional option to define(`confPRIVACY_FLAGS’), then ‘make’, ‘restart’ — no effect, Sendmail still responses by 250-DSN to my EHLO. Is that privacy option still valid in an actual Sendmail version 8.17?
How do you feel about another way of avoiding a backscatter from Sendmail, published on https://know.mailsbestfriend.com/how_to_avoid_backscatter_in_sendmail–799384399.shtml
I am even more concerned about why Sendmail responses ‘Recipient ok’ to RCPT TO: absent@adress? Why does not Sendmail immediately reject an incoming email to an invalid address by defaul?