On 4/15/2016 4:02 PM, Michael D. Sofka wrote: > I would like to be able to reject the empty envelope-sender, <>, for > authenticated email to our submission and smtps ports. That is, I > want to stop: > > 235 2.7.0 Authentication successful > mail from:<> > 250 2.1.0 Ok > rcpt to:<some...@someplace-not-us.com> > 250 2.1.5 Ok > > > Before quoting the RFC, please read on. I am well aware of what I > am asking, and it will not break the RFC, or any legitimate > auto-responder (at least none written this century). > > Here's the problem: > > Near the end of January a phish got through, and about a dozen > people responded. The account information attained was used over > the next couple of weeks to authenticate to port 587, and send > spam. So far, par for the course. Our anti-spam software (CanIt) > is very good, and the envelope-sender was blocked for exceeding the > outgoing email rate limit. > > Except.... > > This spammer/spambot also sent authenticated email with the null > envelope-sender. This had never happened before, and I was > surprised it worked. CanIt again rate-limit-blocked the connecting > IP. It was a higher limit, but fortunately the spammer used a > single IP for the first attempt so the damage was contained. I > quickly added a rule to outgoing messages blocking email: From the > null envelope-sender; with a local authentication header; from a > connecting relay outside of our domain. This rule blocked the next > half dozen-plus, attempts to use the authenticated envelope-sender > loophole. (Side note: It seemed the spambot anticipated the > envelope-sender rate limit, and would first send a burst from the > authenticated account, followed by a second burst from the null > sender.) > > > Running tests, it is indeed the case that Postfix allows the null > envelope-sender on authenticated email (at least up to version > 2.11.0), even with: reject_authenticated_sender_login_mismatch. > Searching for this has only turned up one other request for this > capability, from 2013, with no resolution, and much quoting of the RFC. > > I do understand that rejecting <> in all cases is bad, against the > RFC, would block DSNs, etc. But I don't see a general need for > permitting <> when authenticated, or at the very least see a need to > limit which accounts can authenticate and send as <>. I also do > not see any need to permit <> to relay to a recipient outside of the > local domain, authenticated or not. > > Since early February I have not seen a repeat of the exploit. Since > then have also seen exactly zero cases of the rule preventing > authenticated <> sender to off-domain recipients misfiring. > > If there is a way to prevent authenticated email from the null > sender in Postfix, please advise. I have been reading, and > re-reading the notes on SMTP-AUTH, and so far nothing has helped. > If this is not something Postfix can do, consider this a feature > request. > > Thank You, > Mike >
It's pretty easy to block the null sender on port 587, and I don't think that's an unreasonable request. I'll hope/assume you don't allow AUTH on port 25 since that complicates this. All you need to do is add a check_sender_access map to the master.cf submission service. Simple (incomplete?) example: # main.cf submission_sender_checks = check_sender_access hash:/etc/postfix/reject_null_sender # master.cf # existing submission entry submission ... smtpd ... other options ... # add sender restrictions -o smtpd_sender_restrictions=$submission_sender_checks # reject_null_sender <> REJECT null sender not allowed -- Noel Jones
