Envelope-From when forwarding
Hello Postfix-users!
And hello everyone who may still remember me.
Wietse, Victor, maybe Ralf is still here too..
With very warm regards and memory I'm here again.
LTNS, Very Long!.. :)
It's been long time since I touched email as well, besides
maintaining small postfix instances on servers to accept
some internal emails and forward them to central place.
And it seems quite something has changed when I was away.
For a few days we with a customer of ours were trying to
figure out how to configure current "big" mailservers
("big" in a sense that they're used by large corporations,
bot because they scale well or something) to forward mail
properly. And finally, after quite some work, come to a
conclusion that some of them just CAN NOT be configured.
The thing is that while forwarding (redirecting) mail to
some other address, the system changes envelope-from to
the same address which it is forwarding FROM. For example,
if one wants to forward mail sent from any...@example.com
to address forw...@example.com, so it comes to tar...@example.org,
in the process of forwarding, the envelope-from, which
originally was any...@example.com, is changed to
forw...@example.com. So when tar...@example.org receives
this message, it's envelope-from is not the original but
the forward.
Now imagine what happens when something goes wrong when sending
mail to tar...@example.org. Where the bounce will be sent to?
This is what actually happened here. And no, there was no
mail loop as one can imagine - the mail system does not
forward email with empty envelope-from, - it is dropped
to forw...@example.com MAILBOX!. Well, no mail loop is a
good thing, at least.
We tested 4 big commertial mail servers. Two of them are
MS Exchange and Comunigate Pro. And all 4 behaves exactly
the same - they all change envelope-from when forwarding.
On exchange the admins (I'm not one of them) found no way
to preserve the original envelope-from at all. On CGP,
there IS a way, but the feature is marked as deprecated and
may be dropped in a future release. I know nothing about
the other 2, but at least by default they too change the
envelope-from.
Now when I think about all this, - there's SPF and other
similar technologies, and in this context, changing
envelope-from like this makes sense. But seriously, what
to do with bounces?
Also, who really cares about _envelope_ from? What people
see is *header* from, and it is still easily spoofable
(without cryptography), yet we have this forwarding prob
with _envelope_-from.
I'm in early-days-of-SPF context still, in a perfect world
where email - especially with Postfix - Just Works (and
we have lots of issues with spoofing).
What is the situation now? Where the (email) world is
going to?
Thank you!
/mjt
Re: Envelope-From when forwarding
Welcome back, Michael. [forwarding without changing the envelope From] In a hypothetical world, all email is signed with DKIM, and forwarders don't break DKIM signatures, so that DMARC will accept the messages. The Postfix mailing list still relies on this but it is becoming a curiosity. In a more pragmatic world, forwarders replace the envelope from and update the header From address to align it with the envelope from, and maybe add a header with the original DMARC result. This envelope sender change breaks the reverse channel for delivery status notifications. Some providers implement SRS but that is relatively rare. Basically, anything that requires two-way email forwarding is dead. Wietse
STARTTLS abuse
Hi all, It's postfix 3.1.6-0+deb9u1 on Debian 9. Since enabling STARTTLS on port 25 I'm getting lots of traffic looking like this (relay attempts?): Sep 6 09:17:42 localhost postfix/smtpd[14622]: connect from unknown[77.247.110.240] Sep 6 09:17:42 localhost postfix/smtpd[14622]: setting up TLS connection from unknown[77.247.110.240] Sep 6 09:17:42 localhost postfix/smtpd[14622]: unknown[77.247.110.240]: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH" Sep 6 09:17:42 localhost postfix/smtpd[14622]: unknown[77.247.110.240]: Issuing session ticket, key expiration: 1630916885 Sep 6 09:17:42 localhost postfix/smtpd[14622]: Anonymous TLS connection established from unknown[77.247.110.240]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Sep 6 09:17:42 localhost postfix/smtpd[14622]: lost connection after AUTH from unknown[77.247.110.240] Sep 6 09:17:42 localhost postfix/smtpd[14622]: disconnect from unknown[77.247.110.240] ehlo=2 starttls=1 auth=0/1 commands=3/4 Sep 6 09:17:42 localhost postfix/smtpd[14592]: connect from unknown[77.247.110.240] Sep 6 09:17:42 localhost postfix/smtpd[14592]: setting up TLS connection from unknown[77.247.110.240] Sep 6 09:17:42 localhost postfix/smtpd[14592]: unknown[77.247.110.240]: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH" grep 77.247.110.240 /var/log/mail.log | wc -l 16735 It's a different IP(s) every day so banning them manually is not going to work well. I've tried fail2ban but the postfix and postfix-rbl jails seem to be based on sever error codes which are not produced here e.g: cat /etc/fail2ban/filter.d/postfix.conf # Fail2Ban filter for selected Postfix SMTP rejections # # [INCLUDES] # Read common prefixes. If any customizations available -- read them from # common.local before = common.conf [Definition] _daemon = postfix(-\w+)?/(?:submission/|smtps/)?smtp[ds] failregex = ^%(__prefix_line)sNOQUEUE: reject: RCPT from \S+\[\]: 554 5\.7\.1 .*$ ^%(__prefix_line)sNOQUEUE: reject: RCPT from \S+\[\]: 450 4\.7\.1 Client host rejected: cannot find your hostname, (\[\S*\]); from=<\S*> to=<\S+> proto=ESMTP helo=<\S*>$ ^%(__prefix_line)sNOQUEUE: reject: RCPT from \S+\[\]: 450 4\.7\.1 : Helo command rejected: Host not found; from=<> to=<> proto=ESMTP helo= *$ ^%(__prefix_line)sNOQUEUE: reject: EHLO from \S+\[\]: 504 5\.5\.2 <\S+>: Helo command rejected: need fully-qualified hostname; ^%(__prefix_line)sNOQUEUE: reject: VRFY from \S+\[\]: 550 5\.1\.1 .*$ ^%(__prefix_line)sNOQUEUE: reject: RCPT from \S+\[\]: 450 4\.1\.8 <\S*>: Sender address rejected: Domain not found; from=<\S*> to=<\S+> proto=ESMTP helo=<\S*>$ ^%(__prefix_line)simproper command pipelining after \S+ from [^[]*\[\]:?$ ignoreregex = [Init] journalmatch = _SYSTEMD_UNIT=postfix.service # Author: Cyril Jaquier Any idea how to effectively ban these abusers? Thanks, Adam
Re: STARTTLS abuse
Adam Weremczuk: > Sep? 6 09:17:42 localhost postfix/smtpd[14622]: disconnect from > unknown[77.247.110.240] ehlo=2 starttls=1 auth=0/1 commands=3/4 Use "auth=0/" as a pattern for fail2ban. Wietse
Re: STARTTLS abuse
On Tue, Sep 07, 2021 at 07:42:33PM +0100, Adam Weremczuk wrote: > It's postfix 3.1.6-0+deb9u1 on Debian 9. > > Since enabling STARTTLS on port 25 I'm getting lots of traffic looking > like this (relay attempts?): > > Sep 6 09:17:42 localhost postfix/smtpd[14622]: connect from > unknown[77.247.110.240] > Sep 6 09:17:42 localhost postfix/smtpd[14622]: setting up TLS connection > from unknown[77.247.110.240] > Sep 6 09:17:42 localhost postfix/smtpd[14622]: unknown[77.247.110.240]: TLS > cipher list "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH" > Sep 6 09:17:42 localhost postfix/smtpd[14622]: unknown[77.247.110.240]: > Issuing session ticket, key expiration: 1630916885 > Sep 6 09:17:42 localhost postfix/smtpd[14622]: Anonymous TLS connection > established from unknown[77.247.110.240]: TLSv1.2 with cipher > ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Your TLS log level is too verbose. The recommended TLS log level for normal operation is "1", levels "2" and higher are for short-term diagnostic use only, and only if there's good reason to expect this to be useful, and just drown the most relevant details in noise. > Sep 6 09:17:42 localhost postfix/smtpd[14622]: lost connection after AUTH > from unknown[77.247.110.240] > Sep 6 09:17:42 localhost postfix/smtpd[14622]: disconnect from > unknown[77.247.110.240] ehlo=2 starttls=1 auth=0/1 commands=3/4 > grep 77.247.110.240 /var/log/mail.log | wc -l > 16735 Not enough to matter, less than one per second. > It's a different IP(s) every day so banning them manually is not going > to work well. inetnum:77.247.110.0 - 77.247.110.255 netname:PEENQ-NL-TLN-VPS-01 country:NL geoloc: 52.370216 4.895168 admin-c:PA10298-RIPE tech-c: PA10298-RIPE org:ORG-PNQ1-RIPE status: ASSIGNED PA mnt-by: MNT-PEENQ created:2019-03-01T16:28:00Z last-modified: 2021-02-05T10:53:28Z source: RIPE organisation: ORG-PNQ1-RIPE org-name: PEENQ.NL org-type: OTHER address:Netherlands You could try reaching out to the network provider, web site says: info (at) peenq (dot) nl -- VIktor.
Re: STARTTLS abuse
On Tue, Sep 07, 2021 at 02:50:09PM -0400, Viktor Dukhovni wrote: > inetnum:77.247.110.0 - 77.247.110.255 > netname:PEENQ-NL-TLN-VPS-01 > country:NL > geoloc: 52.370216 4.895168 > admin-c:PA10298-RIPE > tech-c: PA10298-RIPE > org:ORG-PNQ1-RIPE > status: ASSIGNED PA > mnt-by: MNT-PEENQ > created:2019-03-01T16:28:00Z > last-modified: 2021-02-05T10:53:28Z > source: RIPE > > organisation: ORG-PNQ1-RIPE > org-name: PEENQ.NL > org-type: OTHER > address:Netherlands > > You could try reaching out to the network provider, web site says: > > info (at) peenq (dot) nl Also, the reverse (PTR) zone points back to "estoxy.com": 110.247.77.in-addr.arpa. SOA rdns1.estoxy.com. estoxy.gmail.com. 2021080901 28800 7200 604800 86400 who have an abuse reporting page at: https://panel.estoxy.com/submitticket.php?step=2&deptid=4 That said, SASL credential brute-force attempts use compromised botnet nodes from all over the planet, so ultimately you're playing whack-a-mole. Hence if any one IP address is sourcing large enough batches of AUTH attempts, fail2ban can help cap the oracle response rate. -- VIktor.
Re: STARTTLS abuse
On 2021-09-07 at 14:42:33 UTC-0400 (Tue, 7 Sep 2021 19:42:33 +0100) Adam Weremczuk is rumored to have said: Hi all, It's postfix 3.1.6-0+deb9u1 on Debian 9. Since enabling STARTTLS on port 25 I'm getting lots of traffic looking like this (relay attempts?): This does not actually have anything to do with STARTTLS. Sep 6 09:17:42 localhost postfix/smtpd[14622]: connect from unknown[77.247.110.240] Sep 6 09:17:42 localhost postfix/smtpd[14622]: setting up TLS connection from unknown[77.247.110.240] Sep 6 09:17:42 localhost postfix/smtpd[14622]: unknown[77.247.110.240]: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH" Sep 6 09:17:42 localhost postfix/smtpd[14622]: unknown[77.247.110.240]: Issuing session ticket, key expiration: 1630916885 Sep 6 09:17:42 localhost postfix/smtpd[14622]: Anonymous TLS connection established from unknown[77.247.110.240]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Sep 6 09:17:42 localhost postfix/smtpd[14622]: lost connection after AUTH from unknown[77.247.110.240] Sep 6 09:17:42 localhost postfix/smtpd[14622]: disconnect from unknown[77.247.110.240] ehlo=2 starttls=1 auth=0/1 commands=3/4 Sep 6 09:17:42 localhost postfix/smtpd[14592]: connect from unknown[77.247.110.240] Sep 6 09:17:42 localhost postfix/smtpd[14592]: setting up TLS connection from unknown[77.247.110.240] Sep 6 09:17:42 localhost postfix/smtpd[14592]: unknown[77.247.110.240]: TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH" grep 77.247.110.240 /var/log/mail.log | wc -l 16735 That's AUTH probing. A bot on 77.247.110.240 has a big list of usernames and password and is testing them one at a time. It's a different IP(s) every day so banning them manually is not going to work well. If you only offer AUTH on submission services (ports 465 and 587) you can safely block large chunks of network space from accessing those ports. The networks were these sorts of bots are common are almost certain to never have one of your legitimate users on them trying to authenticate. In fact, for most mail systems, one can safely drop packets headed to 465 and 587 for the overwhelming bulk of the Internet and never cause trouble. I've tried fail2ban but the postfix and postfix-rbl jails seem to be based on sever error codes which are not produced here e.g: As has been suggested, looking for 'auth=0/' in the log is a useful pattern for fail2ban or other log-scanning tools. Any idea how to effectively ban these abusers? To start, disable AUTH on port 25. You may need to get users (and devices that generate mail) to change their configs to use port 587 (with STARTTLS & AUTH) or 465 (with implicit TLS & AUTH) before making that change. With no legitimate users trying to authenticate on port 25 and no advertisement of AUTH on port 25, you should see a huge reduction in port 25 AUTH probing. You will still see probes on 465/587 but you can block those either with something like fail2ban looking for 'auth=0/' repeatedly from the same address and/or by manually finding those addresses and passing your own judgment on whether the enclosing /24 (or even /4!) can be safely blocked from those ports. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
