Solved Backscatter from Sendmail

[vienuolis]

Why Sendmail always responds by “Recipient ok” in RCPT TO: fake, non-existent absent@adress?

Such fraud is dangerous because it opens the door for backscattering (outscatter, blowback, misdirected bounces, collateral spam) — always replying by mailer-daemon undelivered notifications to real addresses, quoting URLs and other spam stuff.

I have studied Sendmail/cf/README twice, and did not find yet appropriate settings to avoid such false response. Some advices on the net seems misleading to me. I think Sendmail (like Exim does by default) should first check for existence of mailbox immediately after receiving RCPT TO, and return permanent error before disconnecting submission, thus letting a remote server to inform its local sender about an invalid address and undelivered email.

What have I missed that is obvious? Thank you in advance.

 

[SirDice]

should first check for existence of mailbox immediately after receiving RCPT TO, and return permanent error before disconnecting submission

This opens the door for an account enumeration attack (there are different responses if an account exists or not).

 

[zirias@]

This opens the door for an account enumeration attack (there are different responses if an account exists or not).

Although this is a valid concern, the problem persists: The sender must be notified of undeliverable mail. Without rejecting the mail during the SMTP dialog, the only way to do so is to send out a bounce. Sending out lots of invalid bounces (to faked sender addresses) in response to attempts by spam/malware bots will get your domain quickly blacklisted.

So, you only have two choices: Reject invalid recipients in the SMTP dialog, or violate RFCs by just "blackholing" that mail. Both not perfect, but if you send bounces, you'll jeopardize your site's ability to send legitimate mail.

 

[vienuolis]

zirias@, thank you for the clear explanation.

Although I did not find the right configuration anywhere, I successfully tested /etc/mail/access with a bit strange ruleset:

To:my.username@  RELAY
...
To:our.domain  error:5.1.1:"550 User unknown"
...

It is now the second day of clean running Sendmail.

 

[Jose]

So, you only have two choices: Reject invalid recipients in the SMTP dialog, or violate RFCs by just "blackholing" that mail. Both not perfect, but if you send bounces, you'll jeopardize your site's ability to send legitimate mail.

There's a third choice: check SPF records. If you're the MX for example.com, you should accept bounces for messages you sent from @example.com addresses. If you're not, I'm going to reject any mail you try to send from @example.com addresses during the SMTP negotiation.

 

[covacat]

sendmail checks for local accounts and replies with user unknown
550 5.1.1 <joepoehoe@domain.dom>... User unknown
if your Cw accounts are not system accounts it may not work (if you deliver to some accounts defined in a database)

 

[zirias@]

There's a third choice: check SPF records. If you're the MX for example.com, you should accept bounces for messages you sent from @example.com addresses. If you're not, I'm going to reject any mail you try to send from @example.com addresses during the SMTP negotiation.

For the scenario discussed here, that's unfortunately out of your control. But with a slight modification (don't reject in the SMTP dialog, but send a bounce only after checking e.g. SPF/DKIM), it can solve it for a large fraction of incoming mail. You'll still have to decide what to do with mail from domains not publishing SPF and/or DKIM: "blackhole" it, or risk being blacklisted for the backscatter you cause.

 

[vienuolis]

I have installed OpenSPF, OpenDKIM and OpenDMARC milters, and my Sendmail checks every incoming message for SPF records. Around half of email is rejected in this way. However, quite a lot of spammers have registered its SPF, also a number of checks fail SPF_request_query_mailfrom() failed and accept spam as neutral, softfail, or neither permitted nor denied by a domain.