Re: sanity-check postfix XCLIENT usage ?
Hi name less On Wed, Oct 21, 2020 at 10:13:54AM -0700, PGNet Dev wrote: > I've online-checked SPF/DMARC records for 'intuit.com'; all _seems_ to be ok. > I've cranked up opendmarc logging level to > MilterDebug 5 > with that, on failed attempt, I see only an unhelpful > Oct 21 09:43:39 mx.example.com opendmarc[7977]: 4CGbb3aX1Pz2N: > intuit.com fail This is not Postfix! > Trying 1st from @gmail.com (or any domain i've tried _other_ than > 'intuit.com') Please see the DMARC policy of gmail.com, especially the "none" policy: | _dmarc.gmail.com. IN TXT "v=DMARC1; p=none; sp=quarantine; […]" > using data pulled from postfix logs for a SUCCESSFUL fr...@gmail.com delivery, > @ an opened 'openssl s_client' session to my postfix external IP, injecting > > XCLIENT NAME=mail-vs1-f46.google.com ADDR=209.85.217.46 PORT=40169 > PROTO=ESMTP HELO=mail-vs1-f46.google.com DESTADDR=203.0.113.1 DESTPORT=25 > MAIL FROM: > RCPT TO: > DATA > test message > (CR/LF) > . > (CR/LF) This mail is not signed by gmail.com! But as the policy is none, it's not rejected or otherwise handled. > Switching to the data pulled from postfix logs for a FAILED fr...@intuit.com > delivery, > again @ an opened 'openssl s_client' session to my postfix external IP, > injecting Please see the DMARC policy of intuit.com, especially the "reject" policy: | _dmarc.intuit.com. IN TXT "v=DMARC1; p=reject; […]" > XCLIENT NAME=55.57.138.139.in-addr.arpa.iphmx.com ADDR=139.138.57.55 > PORT=62440 PROTO=ESMTP HELO=esa3.hc3812-35.iphmx.com DESTADDR=203.0.113.1 > DESTPORT=25 > MAIL FROM: > RCPT TO: > DATA > test message > (CR/LF) > . > (CR/LF) > > fails in the session with > > 550 5.7.1 rejected by DMARC policy for intuit.com > > and is not delivered. This mail is not signed by intuit.com! And SPF interaction is pretty weird for the HELO-only case. So you _must_ use a real signed e-mail to check DMARC interaction. > (1) Is there anything obviously wrong/missing in that^ XCLIENT usage > generally, or in the specific intuit.com case above, that would suggest a > cause for the dmarc/milter FAIL, that 1st needs fixing? No, but it changes almost nothing for DMARC interactions, as DMARC looks on header information, not envelope in almost all cases. Bastian -- Virtue is a relative term. -- Spock, "Friday's Child", stardate 3499.1
Re: sanity-check postfix XCLIENT usage ?
On 10/22/20 3:23 AM, Bastian Blank wrote: > Hi name less > > On Wed, Oct 21, 2020 at 10:13:54AM -0700, PGNet Dev wrote: >> I've online-checked SPF/DMARC records for 'intuit.com'; all _seems_ to be ok. >> I've cranked up opendmarc logging level to >> MilterDebug 5 >> with that, on failed attempt, I see only an unhelpful >> Oct 21 09:43:39 mx.example.com opendmarc[7977]: 4CGbb3aX1Pz2N: >> intuit.com fail > > This is not Postfix! > >> Trying 1st from @gmail.com (or any domain i've tried _other_ than >> 'intuit.com') > > Please see the DMARC policy of gmail.com, especially the "none" policy: > > | _dmarc.gmail.com. IN TXT "v=DMARC1; p=none; sp=quarantine; […]" I know :( This is really a security hole in gmail. Given the popularity of gmail, however, I seriously suggest somehow treating gmail as if it had p=reject, as it should. Sincerely, Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: sanity-check postfix XCLIENT usage ?
> On Oct 22, 2020, at 2:11 PM, Demi M. Obenour wrote: > > I know :( > > This is really a security hole in gmail. Given the popularity of > gmail, however, I seriously suggest somehow treating gmail as if it > had p=reject, as it should. No it should not have "p=reject" that's only for sites that only send "transactional" email. And lack of DMARC is not a "security hole". -- Viktor.
Postfix smtp gets stuck with XCLIENT when using smtps
Hi!
I stumbled upon a possible bug with postfix. I am using postfix 3.4.14, and
when I use XCLIENT command over smtps (not starttls), the session gets stuck
until further input, which causes it to abort the connection due to unexpected
SSL packet.
--
Aki Tuomi
## postconf -nf
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
compatibility_level = 2
default_transport = error
inet_interfaces = loopback-only
inet_protocols = all
mailbox_size_limit = 0
mydestination = $myhostname, dev04.dovecot.net, localhost.dovecot.net, localhost
myhostname = dev04.dovecot.net
mynetworks = 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
readme_directory = no
recipient_delimiter = +
relay_transport = error
relayhost =
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_authorized_xclient_hosts = 127.0.0.1,[::1]
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
defer_unauth_destination
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
virtual_mailbox_domains = example.org
virtual_transport = lmtp:localhost:24
## postconf -Mf
smtp inet n - y - -
smtpd
525inet n - y - -
smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_wrappermode=yes
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_reject_unlisted_recipient=no
-o smtpd_recipient_restrictions=
-o smtpd_relay_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
-o debug_peer_level=9
-o debug_peer_list=127.0.0.1,[::1]
pickup unix n - y 60 1
pickup
cleanup unix n - y - 0
cleanup
qmgr unix n - n 300 1 qmgr
tlsmgr unix - - y 1000?1 tlsmgr
rewrite unix - - y - -
trivial-rewrite
bounce unix - - y - 0
bounce
defer unix - - y - 0
bounce
trace unix - - y - 0
bounce
verify unix - - y - 1
verify
flush unix n - y 1000?0 flush
proxymapunix - - n - -
proxymap
proxywrite unix - - n - 1
proxymap
smtp unix - - y - - smtp
relay unix - - y - - smtp
showq unix n - y - -
showq
error unix - - y - -
error
retry unix - - y - -
error
discard unix - - y - -
discard
local unix - n n - -
local
virtual unix - n n - -
virtual
lmtp unix - - y - - lmtp
anvil unix - - y - 1
anvil
scache unix - - y - 1
scache
## mail log
Oct 22 18:13:33 dev04 postfix/submission/smtpd[11290]: > localhost[::1]: 220
dev04.dovecot.net ESMTP Postfix (Debian/GNU)
Oct 22 18:13:33 dev04 postfix/submission/smtpd[11290]: watchdog_pat:
0x5570313f6a40
Oct 22 18:13:33 dev04 postfix/submission/smtpd[11290]: vstream_fflush_some: fd
17 flush 50
Oct 22 18:13:35 dev04 postfix/submission/smtpd[11290]: vstream_buf_get_ready:
fd 17 got 15
Oct 22 18:13:35 dev04 postfix/submission/smtpd[11290]: < localhost[::1]: EHLO
localhost
Oct 22 18:13:35 dev04 postfix/submission/smtpd[11290]: match_list_match:
localhost: no match
Oct 22 18:13:35 dev04 postfix/submission/smtpd[11290]: match_list_match: ::1:
no match
Oct 22 18:13:35 dev04 postfix/submission/smtpd[11290]: > localhost[::1]:
250-dev04.dovecot.net
Oct 22 18:13:35 dev04 postfix/submission/smtpd[11290]: > localhost[::1]:
250-PIPELINING
Oct 22 18:13:35 dev04 postfix/submission/smtpd[11290]: > localhost[::1]:
250-SIZE 1024
Oct 22 18:13:35 dev04 postfix/submission/smtpd[11290]: > localhost[::1]:
250-VRFY
Oct 22 18:13:35 dev04 postfix/submis
Re: sanity-check postfix XCLIENT usage ?
On 10/22/20 12:25 PM, Viktor Dukhovni wrote: >> On Oct 22, 2020, at 2:11 PM, Demi M. Obenour wrote: >> >> I know :( >> >> This is really a security hole in gmail. Given the popularity of >> gmail, however, I seriously suggest somehow treating gmail as if it >> had p=reject, as it should. > No it should not have "p=reject" that's only for sites that only send > "transactional" email. And lack of DMARC is not a "security hole". "p=quarantine" might be a better choice, but I do consider lack of DMARC to be a security hole. I certainly don't want someone to be able to forge mail that claims to be from me. There are all sorts of nasty social engineering attacks someone could do with that ability, many of which have real-world consequences. Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: sanity-check postfix XCLIENT usage ?
Demi M. Obenour wrote: > Viktor Dukhovni wrote: > >> Demi M. Obenour wrote: > >> This is really a security hole in gmail. Given the popularity of > >> gmail, however, I seriously suggest somehow treating gmail as if it > >> had p=reject, as it should. > > No it should not have "p=reject" that's only for sites that only send > > "transactional" email. And lack of DMARC is not a "security hole". > > "p=quarantine" might be a better choice, but I do consider lack of > DMARC to be a security hole. I certainly don't want someone to be > able to forge mail that claims to be from me. There are all sorts of > nasty social engineering attacks someone could do with that ability, > many of which have real-world consequences. Such as your mail from Gmail through mailing lists such as this one? DMARC breaks traditional mailing list usage because it focuses on the header address not the envelope address. Sites with a strict DMARC policy require mailing lists to either rewrite header addresses to avoid the breakage, or to drop the mail, or other worse alternatives. Strict DMARC policy is why we are often seeing "... via ..." in the From: addresses and the address rewritten now when it is coming from a site that has set a strict DMARC policy. Strict DMARC policy is suitable for banks and other direct mailing use wishing higher security but is not suitable for a user's general email where they want to send mail to mailing lists and have other interactions with the community. Bob
Re: Postfix smtp gets stuck with XCLIENT when using smtps
Aki Tuomi:
> Hi!
>
> I stumbled upon a possible bug with postfix. I am using postfix
> 3.4.14, and when I use XCLIENT command over smtps (not starttls),
> the session gets stuck until further input, which causes it to
> abort the connection due to unexpected SSL packet.
The server is waiting for a TLS handshake.
By design, XCLIENT resets the session state to where it was immediately
after the SMTP client connected. Otherwise, things like milters and
smtpd_client_restrictions would not work porperly. Therefore, the
first thing the SMTPS server will do is wait for a TLS handshake.
Fixed by selectively skipping the TLS handshake.
Wietse
diff -ur /var/tmp/postfix-3.6-20201003/src/smtpd/smtpd.c src/smtpd/smtpd.c
--- /var/tmp/postfix-3.6-20201003/src/smtpd/smtpd.c 2020-10-03
17:53:03.0 -0400
+++ src/smtpd/smtpd.c 2020-10-22 15:57:33.506845176 -0400
@@ -5464,7 +5464,8 @@
* obsolete, so we don't have to provide perfect support.
*/
#ifdef USE_TLS
- if (SMTPD_STAND_ALONE(state) == 0 && var_smtpd_tls_wrappermode) {
+ if (SMTPD_STAND_ALONE(state) == 0 && var_smtpd_tls_wrappermode
+ && state->tls_context == 0) {
#ifdef USE_TLSPROXY
/* We garbage-collect the VSTREAM in smtpd_state_reset() */
state->tlsproxy =
Re: sanity-check postfix XCLIENT usage ?
On 10/22/20 3:35 PM, Bob Proulx wrote: > Demi M. Obenour wrote: >> Viktor Dukhovni wrote: Demi M. Obenour wrote: This is really a security hole in gmail. Given the popularity of gmail, however, I seriously suggest somehow treating gmail as if it had p=reject, as it should. >>> No it should not have "p=reject" that's only for sites that only send >>> "transactional" email. And lack of DMARC is not a "security hole". >> >> "p=quarantine" might be a better choice, but I do consider lack of >> DMARC to be a security hole. I certainly don't want someone to be >> able to forge mail that claims to be from me. There are all sorts of >> nasty social engineering attacks someone could do with that ability, >> many of which have real-world consequences. > > Such as your mail from Gmail through mailing lists such as this one? > DMARC breaks traditional mailing list usage because it focuses on the > header address not the envelope address. That's because MUAs display the From: header, not the envelope address. DMARC is aimed at preventing spoofing. If someone sends a message that claims to be from me, but is not, that could damage my reputation or worse. If GMail had p=reject, such a message would be dropped as a forgery. If a relative of mine gets a message that claims to be from me, but is actually from , they at least have a chance of knowing the message is bogus. > Sites with a strict DMARC policy require mailing lists to either > rewrite header addresses to avoid the breakage, or to drop the mail, > or other worse alternatives. Strict DMARC policy is why we are often > seeing "... via ..." in the From: addresses and the address rewritten > now when it is coming from a site that has set a strict DMARC policy. To me, that is a good thing. I *want* mailing lists to either relay the message without changes, or take ownership of the message body by changing the From: header. Otherwise, they are claiming that I sent a message that I never in fact sent, which is not okay. "... via ..." is what I want to see in a mailing list message. > Strict DMARC policy is suitable for banks and other direct mailing use > wishing higher security but is not suitable for a user's general email > where they want to send mail to mailing lists and have other > interactions with the community. If a mailing list relays mail without changing it, DMARC will pass, since the digital signature will still verify correctly. Changing the message without changing the From: header is spoofing, and mailing list software that does it is broken. > Bob Sincerely, Demi OpenPGP_0xB288B55FFF9C22C1.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: sanity-check postfix XCLIENT usage ?
Demi M. Obenour: > That's because MUAs display the From: header, not the envelope address. > DMARC is aimed at preventing spoofing. If someone sends a message > that claims to be from me, but is not, that could damage my reputation > or worse. If GMail had p=reject, such a message would be dropped > as a forgery. If a relative of mine gets a message that claims to > be from me, but is actually from , > they at least have a chance of knowing the message is bogus. Enough already. Here's a From: header From: Firstname Lastname display name email address Many mail user agents, especially the GUI based ones, display the "Firstname Lastname" part, not the sender address. To see the address one has to take additional steps which many people won't take. What does this mean for ordinary users? There is a sender address that they never see, that is "secured" with DMARC and so on, but it could be total garbage because the user won't see it. What they do see is the completely unprotected "Firstname Lastname" part. Oh, and maybe an indicator that the email it is secure. Wietse
Re: sanity-check postfix XCLIENT usage ?
On 22 Oct 2020, at 17:17, Wietse Venema wrote:= > > Demi M. Obenour: >> That's because MUAs display the From: header, not the envelope address. >> DMARC is aimed at preventing spoofing. If someone sends a message >> that claims to be from me, but is not, that could damage my reputation >> or worse. If GMail had p=reject, such a message would be dropped >> as a forgery. If a relative of mine gets a message that claims to >> be from me, but is actually from , >> they at least have a chance of knowing the message is bogus. > > Enough already. Here's a From: header > >From: Firstname Lastname >display name email address > > Many mail user agents, especially the GUI based ones, display the > "Firstname Lastname" part, not the sender address. To see the address > one has to take additional steps which many people won't take. > > What does this mean for ordinary users? There is a sender address > that they never see, that is "secured" with DMARC and so on, but > it could be total garbage because the user won't see it. > > What they do see is the completely unprotected "Firstname Lastname" > part. Oh, and maybe an indicator that the email it is secure. It's worth pointing out, again, that this means that a From header in a DMARC message like: From: al...@paypal.com Will be shown to the user as being a secured message from "alert@#PayPal.com" -- 'You're your own worst enemy, Rincewind,' said the sword. Rincewind looked up at the grinning men. 'Bet?' --Colour of Magic
Re: sanity-check postfix XCLIENT usage ?
Wietse Venema wrote: > Enough already. Here's a From: header > > From: Firstname Lastname > display name email address > > Many mail user agents, especially the GUI based ones, display the > "Firstname Lastname" part, not the sender address. To see the address > one has to take additional steps which many people won't take. You can mark me down as being really old school because I do actually see most of the interesting headers. For example in the message from you I see exactly this in the headers. (I display this set of message headers in this ordering, From: Reply-To: Resent-From: To: Cc: Mail-Followup-To: Subject: Date:) Date: Thu, 22 Oct 2020 19:17:35 -0400 (EDT) From: Wietse Venema To: Postfix users Subject: Re: sanity-check postfix XCLIENT usage ? Reply-To: Postfix users :-) > What does this mean for ordinary users? There is a sender address > that they never see, that is "secured" with DMARC and so on, but > it could be total garbage because the user won't see it. > > What they do see is the completely unprotected "Firstname Lastname" > part. Oh, and maybe an indicator that the email it is secure. I take advantage of that around April Fool's Day and send them messages from their dog and things like that. :-) > Demi M. Obenour: > > That's because MUAs display the From: header, not the envelope address. > > DMARC is aimed at preventing spoofing. If someone sends a message > > that claims to be from me, but is not, that could damage my reputation > > or worse. If GMail had p=reject, such a message would be dropped > > as a forgery. If a relative of mine gets a message that claims to > > be from me, but is actually from , > > they at least have a chance of knowing the message is bogus. The tragicomical thing is that Gmail does follow policy and when the policy of the sending site is strict DMARC and the mailing list does not rewrite then Gmail subscribers to mailing lists will get automatically unsubscribed when/if the bounce ratio exceeds the threshold! That's perhaps a surprising unintended consequence. Because the sender's message from the mailing list re-sent to the Gmail subscriber is bounced by Gmail back to the mailing list then the mailing list management software counts it as a bounce from the Gmail end against that subscriber. The sender is unmarked. So it depends upon the amount of mailing list traffic and the ratio of mail from strict DMARC sites and not strict. A large flow of non-DMARC traffic will keep the ratio low. But then if on a single day even one strict DMARC sender sends many messages causing many bounces it will trip over the threshold for the Gmail subscribers and result in all of them being unsubscribed all at once. And then a bunch of Gmail subscribers are all left wondering why they were unsubscribed. Sometimes they will even write in to the list admins asking that question. Yes these are actual events. I think the best compromise is that mailing lists must rewrite the headers when handling mail from sites with a strict DMARC policy. Although there are others that have disagreed and wished their email to be discarded rather than modified in any way. Bob
Re: Accessing the sending user from a canonical(5) table
On 18/10/20 11:54 am, Demi M. Obenour wrote: To elaborate, my understanding is that site.net should use MAIL FROM:, but leave the body unchanged. domain.com will then accept the message, as it is from an IP in site.net's SPF record, and DKIM ignores the envelope. Demi Don't forget that in doing this site.net will also be expected to handle bounce notifications, and then forward them back to the original from address. :-) Nick.
Re: Limiting HELO spoofing in Postfix?
On 22/10/20 7:24 am, Rich Wales wrote: I would still like to figure out a way, btw, to catch locally generated spam of this sort in Postfix. I've already asked here about rejecting HELO/EHLO when the client is localhost but the HELO/EHLO host is not localhost -- I still think this would make sense, but I'm getting the clear impression that it's just not there and just isn't going to get added. Or maybe I can reduce my use of permit_mynetworks in my configuration -- I am currently invoking permit_mynetworks in my client, HELO, sender, relay, and recipient smtpd restrictions, maybe this is excessive. This sounds like the perfect candidate for a simple access policy. See: http://www.postfix.org/SMTPD_POLICY_README.html In summary, you'd want to create a script in a language of your choice, which in the simplest case does this: 1. Reads in lines until a blank line. 2. Then sees if the lines that it read included the line "client_address=127.0.0.1". 3. If it did, then it checks if it also received the line "helo_name=localhost". 4. Then it outputs a result based on the results of steps #2 & #3: * If #2 matched and #3 matched, then it prints "dunno", followed by a blank line. * If #2 matched but #3 didn't, then it prints "reject You look like you're trying to get me to send spam", followed by a blank line. * If #2 didn't match, then it prints "dunno", followed by a blank line. NB: The reason for using "dunno" (rather than "ok") is so that other following checks will still be performed. Then: 1. Configure a new service in master.cf to run your script (using spawn). 2. Add "check_policy_service" into your smtpd_helo_restrictions option (before permit_mynetworks) to tell postfix to use the script. Of course I've glossed over a lot of detail, and so I'd recommend reading the Postfix documentation and/or looking at some example policies (e.g. I use postfix-policyd-spf-python for SPF) to get your head around how policies work, before implementing what I suggested above. Also remember "warn_if_reject" is your best friend when writing policy scripts! :-) Nick.
Re: Forward mail and obey SPF and DKIM
On 18/10/20 7:10 am, IL Ka wrote: Thank you all. This is how I fixed it (after Bill Cole's email): I needed to substitute envelope (MAIL FROM:) to match my address, but the message (along with it's headers) shouldn't be touched. sender_canonical_classes = envelope_sender # Only change envelope, not body sender_canonical_maps = regexp:/etc/postfix/sender_canonical_map # In this file I change envelope address to my domain. Google is now perfectly happy with both SPF and DKIM. Shouldn't we add this recipe to the official postfix documentation? Don't forget about bounce notifications. So rather than rewriting addresses using sender_canonical_maps, you might be better off looking into Sender Rewriting Scheme (SRS)? Nick.
Re: Limiting HELO spoofing in Postfix?
I've made one change to my configuration which may help handle the locally generated spam problem, at least in the case of the "fake open relay" mail. I have removed permit_mynetworks from my smtpd_relay_restrictions. (I still have permit_mynetworks in the smtpd client, HELO, sender, and recipient restrictions.) In case this change might have broken something (which it doesn't appear to have done), I also enabled soft_bounce=yes. Shortly thereafter, I found one (and, so far, only one) incident in my log where an open relay message apparently originated from my server itself. It looks strange, though. Check out the following log excerpt and note particularly what happened with regard to the postscreen process: Oct 21 20:22:33 memoryalpha postfix/postscreen[4751]: CONNECT from [193.169.253.190]:63634 to [10.0.229.197]:25 Oct 21 20:22:33 memoryalpha postfix/dnsblog[4752]: addr 193.169.253.190 listed by domain hostkarma.junkemailfilter.com as 127.0.1.1 Oct 21 20:22:33 memoryalpha postfix/dnsblog[4752]: addr 193.169.253.190 listed by domain hostkarma.junkemailfilter.com as 127.0.0.2 Oct 21 20:22:33 memoryalpha postfix/dnsblog[4758]: addr 193.169.253.190 listed by domain zen.spamhaus.org as 127.0.0.4 Oct 21 20:22:33 memoryalpha postfix/dnsblog[4758]: addr 193.169.253.190 listed by domain zen.spamhaus.org as 127.0.0.3 Oct 21 20:22:33 memoryalpha postfix/dnsblog[4752]: addr 193.169.253.190 listed by domain dnsbl.justspam.org as 127.0.0.2 Oct 21 20:22:33 memoryalpha postfix/dnsblog[4757]: addr 193.169.253.190 listed by domain bl.spamcop.net as 127.0.0.2 Oct 21 20:22:33 memoryalpha postfix/postscreen[4751]: CONNECT from [127.0.0.1]:40434 to [127.0.0.1]:25 Oct 21 20:22:33 memoryalpha postfix/postscreen[4751]: WHITELISTED [127.0.0.1]:40434 Oct 21 20:22:33 memoryalpha postfix/smtpd[4764]: connect from localhost[127.0.0.1] Oct 21 20:22:33 memoryalpha postfix/dnsblog[4759]: addr 193.169.253.190 listed by domain score.senderscore.com as 127.0.4.0 Oct 21 20:22:34 memoryalpha postfix/dnsblog[4760]: addr 193.169.253.190 listed by domain truncate.gbudb.net as 127.0.0.2 Oct 21 20:22:34 memoryalpha postfix/smtpd[4764]: NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 454 4.7.1 : Relay access denied; from= to= proto=ESMTP helo= Oct 21 20:22:34 memoryalpha postfix/smtpd[4764]: disconnect from localhost[127.0.0.1] ehlo=1 mail=1 rcpt=0/1 rset=1 quit=1 commands=4/5 Oct 21 20:22:39 memoryalpha dovecot: imap-login: Aborted login (no auth attempts in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, secured, session= Oct 21 20:22:39 memoryalpha postfix/postscreen[4751]: DNSBL rank 78 for [193.169.253.190]:63634 Oct 21 20:22:40 memoryalpha postfix/postscreen[4751]: NOQUEUE: reject: RCPT from [193.169.253.190]:63634: 450 4.7.1 Service unavailable; client [193.169.253.190] blocked using zen.spamhaus.org; from=, to=, proto=ESMTP, helo= Oct 21 20:22:40 memoryalpha postfix/postscreen[4751]: DISCONNECT [193.169.253.190]:63634 The postscreen process (PID 4751) initially fielded a connection from 193.169.253.190 (port 63634) -- an IP address, btw and fwiw, which is assigned to a hosting service in Estonia. But before rejecting this connection (because the IP address was blacklisted), another connection sprang into life from 127.0.0.1 (port 40434). Basically, it looks to me as if the connection from 127.0.0.1 was somehow nested inside the connection from 193.169.253.190. This could just be a coincidence, but the fact that all this activity happened within a single postscreen process (PID 4751) confuses me -- can anyone explain this? For what it's worth, there is no other activity with PID 4751 anywhere else in sight in my log. Also, the sender and recipient e-mail addresses for the 193.169.253.190 and 127.0.0.1 connections are the same -- another seemingly very strong indication that they are somehow related, though it's not clear to me how. Correlating the above with other logs on my server, an inbound SMTP connection from 193.169.253.190 on remote port 63634 was accepted and logged by iptables. No connections from 193.169.253.190 show up in my server's Apache logs. So, again, can anyone suggest an explanation for why a complete Postfix connection from 127.0.0.1 is seemingly embedded inside a complete Postfix connection from 193.169.253.190? In case it matters, I'm running Postfix 3.3.0, installed as a package on an Ubuntu 18.04.5 LTS system. I'm not knowingly enabling XCLIENT in my Postfix configuration for what this might be worth. Thanks for any thoughts. Rich Wales ri...@richw.org
Re: Limiting HELO spoofing in Postfix?
On Thu, Oct 22, 2020 at 10:44:06PM -0700, Rich Wales wrote: > I have removed permit_mynetworks from my smtpd_relay_restrictions. (I > still have permit_mynetworks in the smtpd client, HELO, sender, and > recipient restrictions.) In case this change might have broken > something (which it doesn't appear to have done), I also enabled > soft_bounce=yes. This of course disables outbound submission on port 25, but that's generally a good idea anyway. > Shortly thereafter, I found one (and, so far, only one) incident in my > log where an open relay message apparently originated from my server > itself. > > Oct 21 20:22:33 memoryalpha postfix/postscreen[4751]: CONNECT from > [193.169.253.190]:63634 to [10.0.229.197]:25 > [...] The source IP is listed by multiple RBLs (perhaps a few too many configured, but whatever...) > Oct 21 20:22:33 memoryalpha postfix/postscreen[4751]: CONNECT from > [127.0.0.1]:40434 to [127.0.0.1]:25 > Oct 21 20:22:33 memoryalpha postfix/postscreen[4751]: WHITELISTED > [127.0.0.1]:40434 > Oct 21 20:22:33 memoryalpha postfix/smtpd[4764]: connect from > localhost[127.0.0.1] Fascinating, this would be a good time to post your master.cf settings, i.e. verbatim, without refolding of lines output of: $ postconf -Mf and also your main.cf settings, i.e. verbatim, without refolding of lines output of: $ posconf -nf > Oct 21 20:22:34 memoryalpha postfix/smtpd[4764]: NOQUEUE: reject: RCPT > from localhost[127.0.0.1]: 454 4.7.1 : Relay access > denied; from= to= proto=ESMTP > helo= Yes, the HELO name, sender and recipient above match the corresponding information in the postscreen reject message below. > Oct 21 20:22:39 memoryalpha dovecot: imap-login: Aborted login (no auth > attempts in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, secured, > session= But note also "dovecot" showing up here. It looks like the spammer is using some feature of Dovecot to originate a connection to the Postfix SMTP server. > Oct 21 20:22:39 memoryalpha postfix/postscreen[4751]: DNSBL rank 78 for > [193.169.253.190]:63634 Impressive DNSBL score! > Oct 21 20:22:40 memoryalpha postfix/postscreen[4751]: NOQUEUE: reject: > RCPT from [193.169.253.190]:63634: 450 4.7.1 Service unavailable; client > [193.169.253.190] blocked using zen.spamhaus.org; > from=, to=, proto=ESMTP, > helo= Note the matching "helo". The two connections sure look related. > The postscreen process (PID 4751) initially fielded a connection from > 193.169.253.190 (port 63634) -- an IP address, btw and fwiw, which is > assigned to a hosting service in Estonia. But before rejecting this > connection (because the IP address was blacklisted), another connection > sprang into life from 127.0.0.1 (port 40434). Perhaps via some component of Dovecot? Is your Dovecot up to date and patched? > Basically, it looks to me > as if the connection from 127.0.0.1 was somehow nested inside the > connection from 193.169.253.190. No, not nested inside, just concurrent. > This could just be a coincidence, but > the fact that all this activity happened within a single postscreen > process (PID 4751) confuses me -- can anyone explain this? There's only ever one postscreen process, it handles multiple concurrent connections, that is its purpose in life. See POSTSCREEN_README. > Correlating the above with other logs on my server, an inbound SMTP > connection from 193.169.253.190 on remote port 63634 was accepted and > logged by iptables. No connections from 193.169.253.190 show up in my > server's Apache logs. It looks more like connection proxying then a web server exploit. > So, again, can anyone suggest an explanation for why a complete Postfix > connection from 127.0.0.1 is seemingly embedded inside a complete > Postfix connection from 193.169.253.190? Your Postfix and Dovecot configurations would be useful at this point. -- Viktor.
Re: Limiting HELO spoofing in Postfix?
On Fri, Oct 23, 2020 at 02:14:58AM -0400, Viktor Dukhovni wrote: > On Thu, Oct 22, 2020 at 10:44:06PM -0700, Rich Wales wrote: > > Oct 21 20:22:39 memoryalpha dovecot: imap-login: Aborted login (no auth > > attempts in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, secured, > > session= > > But note also "dovecot" showing up here. It looks like the spammer is > using some feature of Dovecot to originate a connection to the Postfix > SMTP server. Of course that could just be smtpd enabling Dovecot auth, though you should probably not enable SASL on port 25. In which case "Dovecot" may be a distraction. > > > Oct 21 20:22:40 memoryalpha postfix/postscreen[4751]: NOQUEUE: reject: > > RCPT from [193.169.253.190]:63634: 450 4.7.1 Service unavailable; client > > [193.169.253.190] blocked using zen.spamhaus.org; > > from=, to=, proto=ESMTP, > > helo= > > Note the matching "helo". The two connections sure look related. One interesting question is whether you somehow have TCP fast open enabled by default. If the purpose of the first connection is to obtain a TFO cookie, and somehow the second connection is able to use this cookie (weak validation?) to send an entire SMTP transaction along with the SYN packet, but this time with 127.0.0.1 as the source address, then the use of two connections for the attack starts to make sense. Of course TFO is supposed to provide some cryptographic protection against spoofing the source address. So something odd is happening if that's the actual story. Do you have any non-default network kernel parameter settings that might be related to TCP fastopen? Perhaps a previously implanted backdoor makes this form of attack possible. -- Viktor.
