Google is at it again
I have a crontab set up to send me regular reminders on my local mail account. I've added reminders for a person with a Google mail account. They haven't been getting the reminders lately. By doing some testing, I found that Google was silently rejecting mail from my workstation. The fix was easy: configure relayhost in PostFix on my workstation to send mail through my registered mailserver. I know this is basic Postfix-fu, but I'm sending this little, um, reminder to the mailing list, in case someone else has been scratching their head over mail to Google being black-holed.
Re: Google is at it again
On Fri, Sep 16, 2022, Stephen Satchell wrote: > By doing some testing, I found that Google was silently rejecting mail from What does "silently rejecting" mean? Do you mean "accepting the mail but not delivering to the recipient" (not even to the infamous "spam folder")?
Re: Google is at it again
On Fri, Sep 16, 2022 at 01:39:19AM -0700, Stephen Satchell wrote: > By doing some testing, I found that Google was silently rejecting mail > from my workstation. The fix was easy: configure relayhost in PostFix > on my workstation to send mail through my registered mailserver. To add some meaningful content to this message, you should ideally share a log entry showing blackholed delivery, inquire and note clearly what happened to the message on the other end (disappeared, spam foldered, ...), and also note whether you have SPF records (if so what they are, and do they match the source IP address of the machine in question), are doing DKIM signing, ... -- Viktor.
Re: Google is at it again
On 2022-09-16 at 04:43:35 UTC-0400 (Fri, 16 Sep 2022 08:43:35 +) Claus Assmann is rumored to have said: On Fri, Sep 16, 2022, Stephen Satchell wrote: By doing some testing, I found that Google was silently rejecting mail from What does "silently rejecting" mean? That is a good question, as it seems to me to be impossible in SMTP. If Google is giving a 4xx or 5xx reply code in SMTP and you never hear about it, that is not Google's fault, and it is NOT silent rejection. This is why one should always stand up the local mail subsystem on any server that generates email and deliver through that, so that there's a fault-handling mechanism that can do any needed retries or alerts to failures. Do you mean "accepting the mail but not delivering to the recipient" (not even to the infamous "spam folder")? That would be novel for Google. MS has always done it but not everyone concurs with that being 'innovative' in any positive sense. -- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
Re: Google is at it again
Stephen Satchell: > I have a crontab set up to send me regular reminders on my local mail > account. I've added reminders for a person with a Google mail account. > They haven't been getting the reminders lately. > > By doing some testing, I found that Google was silently rejecting mail > from my workstation. The fix was easy: configure relayhost in PostFix > on my workstation to send mail through my registered mailserver. What kind of SMTP client is this? Does it produce any logs? Wietse > I know this is basic Postfix-fu, but I'm sending this little, um, > reminder to the mailing list, in case someone else has been scratching > their head over mail to Google being black-holed. >
Re: Google is at it again
On 16/09/2022 09:39, Stephen Satchell wrote: I have a crontab set up to send me regular reminders on my local mail account. I've added reminders for a person with a Google mail account. They haven't been getting the reminders lately. By doing some testing, I found that Google was silently rejecting mail from my workstation. The fix was easy: configure relayhost in PostFix on my workstation to send mail through my registered mailserver. By any chance the port 25 is blocked in the firewall? I do that to prevent infected machines from sending Spam? I know this is basic Postfix-fu, but I'm sending this little, um, reminder to the mailing list, in case someone else has been scratching their head over mail to Google being black-holed.
Re: Google is at it again
FYI: the OP replied to me directly (not sure why) - indicating that Google "silently dropped" the e-mail even though the log shows it was accepted (and it wasn't delivered to the "spam folder" either).
Re: Google is at it again
On 9/16/22 9:08 AM, Claus Assmann wrote: FYI: the OP replied to me directly (not sure why) - indicating that Google "silently dropped" the e-mail even though the log shows it was accepted (and it wasn't delivered to the "spam folder" either). Why: pushed the wrong button in Thunderbird Test: I have some Google mail accounts, so when I tried to send mail to them they disappeared in the ether. Fix: load PostFix into the workstation (if not already there), and set relay_host in main.cf to point to my properly configured mail server. That mail server running PostFix, of course, with no known problems. :) SPF does not include all my external IP addresses; I decided to leave it that way for the same reason that someone else mentioned: no direct outbound mail from unauthorized workstations. My fiber edge router is at ***.***.***.161; my mail server is on ***.***.***.165; I suspect Google failed the mail because the SPF TXT record said "fail". Someone dropped the DNR. At this point my problems are fixed, so I'm not looking further into this. *NOT* a PostFix problem: found another issue, this time in an Ubuntu workstation, in that I had to set the domain in mailutils.conf so that I didn't need to make the workstation host name a FQDN. This is a configuration problem with the Ubuntu mailutils package. There are scripts running on the Ubuntu workstation that use "mail" instead of "mailx". (Possible conflict between Ubuntu's mailutils and postfix packages?)
Re: Google is at it again
On 17/9/22 00:08, Claus Assmann wrote: FYI: the OP replied to me directly (not sure why) - indicating that Google "silently dropped" the e-mail even though the log shows it was accepted (and it wasn't delivered to the "spam folder" either). Just a thought, as to why the OP replied direct to you - mayhap the reply that the OP composed, defaulted to Reply To sender, rather than Reply To list, and this was overlooked by the OP? My reply is written in Thunderbird, which has two options; Reply (to sender) and Reply List - mayhap, if the OP faced the same options, the OP chose (perhaps, inadvertently) Reply (to sender) rather than Reply List? .. Bret Busby Armadale West Australia (UTC+0800) ..
Re: Google is at it again
On 16.09.22 16:08, Claus Assmann wrote: FYI: the OP replied to me directly (not sure why) - indicating that Google "silently dropped" the e-mail even though the log shows it was accepted (and it wasn't delivered to the "spam folder" either). we have noticed these reports already some time ago. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Windows found: (R)emove, (E)rase, (D)elete
Why sometimes milters don't run?
In my setup reject_unlisted_recipient is in smtpd_data_restrictions. I have milters that run, including during the RCPT command. Normally, I can observe the milters run before postfix rejects for "User unknown in virtual mailbox table" by reject_unlisted_recipient in smtpd_data_restrictions. Every once in a while I observe the milters don't run during the RCPT command, and some how progressed straight to DATA. Logs for one of these times, the real domain was replaced with example.com Sep 15 05:34:39 hostname postfix/smtpd[229290]: connect from mail-qk1-f200.google.com[209.85.222.200] Sep 15 05:34:40 hostname postfix/smtpd[229290]: 4MSsVS1zdpz7VvCp: client=mail-qk1-f200.google.com[209.85.222.200] Sep 15 05:34:40 hostname postfix/smtpd[229290]: 4MSsVS1zdpz7VvCp: reject: DATA from mail-qk1-f200.google.com[209.85.222.200]: 550 5.1.1 : Recipient address rejected: \ User unknown in virtual mailbox table; from= to= proto=ESMTP helo= Sep 15 05:35:10 hostname postfix/smtpd[229290]: timeout after RSET from mail-qk1-f200.google.com[209.85.222.200] Sep 15 05:35:10 hostname postfix/smtpd[229290]: disconnect from mail-qk1-f200.google.com[209.85.222.200] ehlo=2 starttls=1 mail=1 rcpt=1 data=0/1 rset=1 commands=6/7 If I send myself a test email to the same address they used (d...@example.com) the milters run during the RCPT command and don't behave in the same manor as the above logs. I understand the above logged session is from a bad actor doing something "exploity", I just don't know what. Any idea what they are doing during that session that would cause the RCPT command / milters to not happen as they normally would?
Re: Why sometimes milters don't run?
If Postfix rejects an SMTP event (connect, ehlo, data, and so on), then Postfix will not send that event to the Milters. If it passed all SMTP events to Milters, then they would get out of sync with Postfix. Wietse
Re: Why sometimes milters don't run?
On 09-16-2022 3:16 pm, Wietse Venema wrote: If Postfix rejects an SMTP event (connect, ehlo, data, and so on), then Postfix will not send that event to the Milters. If it passed all SMTP events to Milters, then they would get out of sync with Postfix. Is it possible for a client to include non displaying characters in a RCPT TO address and those characters would get passed to the milters? Or does postfix filter out "improper" characters before sending the RCPT TO address to the milters?
Re: Why sometimes milters don't run?
post...@ptld.com: > > On 09-16-2022 3:16 pm, Wietse Venema wrote: > > If Postfix rejects an SMTP event (connect, ehlo, data, and so on), > > then Postfix will not send that event to the Milters. If it passed > > all SMTP events to Milters, then they would get out of sync with > > Postfix. > > Is it possible for a client to include non displaying characters > in a RCPT TO address and those characters would get passed to the > milters? Or does postfix filter out "improper" characters before > sending the RCPT TO address to the milters? Whatever Postfix allows in an RCPT TO command, that will be sent to a Milter. The domain portion of an email address must contain valid domain name syntax, but there are few restrictions on what it allows in an address localpart (no carriage return or linefeed). Wietse
Re: Unexpected record type 'X'
On 2022-09-06 23:18, Viktor Dukhovni wrote: On Tue, Sep 06, 2022 at 09:43:38PM -0400, J Doe wrote: Out of curiosity ... why do queue files require the execute bit ? That's how they're marked "complete". A partially written queue file is just read-write. When a queue is committed it is marked executable and synced to disk, at that point the SMTP server can tell the remote client that the file is safely persisted in the queue. Hi Viktor, Ah, neat! Thanks for satisfying my curiosity. - J
