2
Looks like SM will accept a message for a disabled account over SMTP, then generate an outgoing bounce back to sender?
Question asked by josh levine - 9/29/2024 at 8:44 PM
Answered
Looks like SM will accept a message for a disabled account over SMTP...
[2024.09.29] 21:10:58.008 [59.59.90.196][65038424] rsp: 250 OK <contact@WHATMAN.COM> Sender ok
[2024.09.29] 21:10:58.008 [59.59.90.196][65038424] Sender accepted. Weight: 0. 
[2024.09.29] 21:10:58.258 [59.59.90.196][65038424] cmd: RCPT TO: <contact@test.com>
[2024.09.29] 21:10:58.258 [59.59.90.196][65038424] rsp: 250 OK <contact@test.com> Recipient ok
...then generate an outgoing bounce back to sender during delivery...
[2024.09.29] 21:11:11.144 [65265906] Starting local delivery to contact@test.com
[2024.09.29] 21:11:11.144 [65265906] Delivery for contact@WHATMAN.COM to contact@test.com has bounced. Reason: The recipient does not exist
[2024.09.29] 21:11:11.347 [65265906] DSN email written to 65265907 with status failed to contact@test.com
(`contact@test.com` is a disabled account)

These then get usually stuck in the queue since they are from spammers. 

Seems like it would make more sense to check if the account is disabled before sending back the "250 OK" to the "RCPT TO:" during the SMTP transaction? 

Is this possible to configure?

Thanks!

-josh



6 Replies

Reply to Thread
1
Tony Scholz Replied
Employee Post
Hello Josh, 

What version of SmarterMail are you running? When I test this locally the bounce is during the SMTP session? 

10:50:30.342 [127.0.0.1][37118524] cmd: MAIL FROM:<fake_user@fake_doamin.tld> BODY=8BITMIME SMTPUTF8
10:50:30.342 [127.0.0.1][37118524] senderEmail(1): fake_user@fake_doamin.tld
10:50:30.342 [127.0.0.1][37118524] rsp: 250 OK <fake_user@fake_doamin.tld> Sender ok
10:50:30.342 [127.0.0.1][37118524] Sender accepted. Weight: 0. 
10:50:30.342 [127.0.0.1][37118524] cmd: RCPT TO:<acquaintances.sbin.testing@ascholz.io>
10:50:30.346 [127.0.0.1][37118524] acquaintances.sbin.testing@ascholz.io is disabled.
10:50:30.346 [127.0.0.1][37118524] rsp: 551 <acquaintances.sbin.testing@ascholz.io> No such user here
10:50:30.349 [127.0.0.1][37118524] disconnected at 10/1/2024 10:50:30 AM

In this case the user is set up as "Disabled (do not allow mail)". Running version 100.0.9035.22254 (Sep 26, 2024)




Tony Scholz System/Network Administrator SmarterTools Inc. www.smartertools.com
0
josh levine Replied
SmarterMail Professional
Build 8664 (Sep 21, 2023)

Also, there is a catch-all on the domain so maybe that matters?

Thanks!

-josh
0
Tony Scholz Replied
Employee Post Marked As Answer
Hello Josh, 

This has been resolved in the more recent versions. you will want to upgrade to get this fix when you have the chance. Do to this thread I did find another small issue with this as well that has since been fixed. 

Build 9028 (Sep 19, 2024)
Fixed: Administrators can send emails when impersonating a user that is set to "Disabled (do not allow email)".
Tony Scholz System/Network Administrator SmarterTools Inc. www.smartertools.com
0
David Fisher Replied
Hi Josh,

  I would think having a catch-all could be the issue, as on the SMTP level it will allow *@whatman.com as there is a catch-all configured for the domain, correct?

  So when it goes to try and delivery it to the local user, it would find that account is disabled (do not allow email) and bounce it instead of going to the catch-all email address, correct?

  Wouldn't this be the case Tony?
0
Jereming Chen Replied
Employee Post
Hello,

In the more recent versions of SmarterMail, the catch-all alias does not interfere, so it should not be an issue. In fact, it is as David said. During Delivery to the local user, SmarterMail will see that it is a disabled account and reply with a bounce message, if it was configured to. Funny enough, when you have a catch-all alias in place, this is one of the few ways you could still get a bounce message saying "Recipient does not exist"

Jereming Chen System/Network Administrator SmarterTools Inc. www.smartertools.com
0
josh levine Replied
I confirmed sending an email to an alias that points to a disabled account now silently discards the message...

```
Delivery for xxx@gmail.com to disabled@xxx.com(disabled-alias@xxx.com) skipped bounce due to delivery to alias. Bounce reason: RecipientDoesNotExist
```

This is much better than generating a bounce, but not great because the sender will never know that the address is disabled and that email was discarded.

Best would be to reject the email after the SMTP "RCPT TO:" line. This would prevent the message from ever even getting to the spool and would immediately let the sender know that the message is undeliverable.

Thanks!

Reply to Thread