Greg Sims via Postfix-users: > On Tue, May 28, 2024 at 8:12?AM Greg Sims <g...@raystedman.org> wrote: > > > > On Tue, May 28, 2024 at 6:49?AM Wietse Venema via Postfix-users > > <postfix-users@postfix.org> wrote: > > > > > In recent experience with my personal porcupine.org email address, > > > they not only want SPF or DKIM, they *also* want a DMARC policy > > > with p=quarantine or p=reject. > > > > We have run p=reject for years. DMARC is currently p=none because of the > > issue you are helping with. I feel like we have a solution now -- time > > will tell. I hope to be p=reject once again soon! > > > > Thanks Wietse, Greg > > We have our bounce messages being stored in a local mailbox > bounce-local -- this is working well. Unfortunately the SPF Failure > we see in the logs is not being sent to bounce-local. Please see the > following "collate" sequence: > > Jun 02 02:19:21 mail01.raystedman.org postfix/bounce[26402]: > B9A1C305D596: sender non-delivery notification: EF978305D5BA
EF978305D5BA is a non-delivery notification for message B9A1C305D596. > Jun 02 02:19:21 mail01.raystedman.org postfix/cleanup[26400]: > EF978305D5BA: message-id=<20240602091921.ef978305d...@mail01.raystedman.org> > Jun 02 02:19:21 mail01.raystedman.org postfix/qmgr[1311]: > EF978305D5BA: from=<>, size=36846, nrcpt=1 (queue active) > Jun 02 02:19:22 mail01.raystedman.org postfix/t121/smtp[26247]: > Trusted TLS connection established to > aspmx.l.google.com[142.251.2.26]:25: TLSv1.3 with cipher > TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 > server-signature ECDSA (P-256) server-digest SHA256 > Jun 02 02:19:22 mail01.raystedman.org postfix/t121/smtp[26247]: > EF978305D5BA: host aspmx.l.google.com[142.251.2.26] said: 421-4.7.26 > Your email has been rate limited because it is unauthenticated. Gmail > 421-4.7.26 requires all senders to authenticate with either SPF or > DKIM. 421-4.7.26 421-4.7.26 Authentication results: 421-4.7.26 DKIM > = did not pass 421-4.7.26 SPF [] with ip: [209.73.152.121] = did not > pass 421-4.7.26 421-4.7.26 For instructions on setting up > authentication, go to 421 4.7.26 > https://support.google.com/mail/answer/81126#authentication > d2e1a72fcca58-70242b097aasi4749745b3a.183 - gsmtp (in reply to end of > DATA command) Google rejects non-delivery notification message EF978305D5BA after receiving End-of-DATA. The SMTP reply is 421, therefore Postfix will try to deliver EF978305D5BA to an alternate Google server. > Jun 02 02:19:22 mail01.raystedman.org postfix/t121/smtp[26247]: > Trusted TLS connection established to > alt2.aspmx.l.google.com[74.125.126.26]:25: TLSv1.3 with cipher > TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 > server-signature ECDSA (P-256) server-digest SHA256 > Jun 02 02:19:23 mail01.raystedman.org postfix/t121/smtp[26247]: > EF978305D5BA: > to=<en-devo-bounce+<deleted>=icloud....@devotion.raystedman.org>, > relay=alt2.aspmx.l.google.com[74.125.126.26]:25, delay=1.3, > delays=0/0/0.89/0.41, dsn=2.0.0, status=sent (250 2.0.0 OK 1717319963 > ca18e2360f4ac-7eafe6365f9si240806939f.105 - gsmtp) > Jun 02 02:19:23 mail01.raystedman.org postfix/qmgr[1311]: > EF978305D5BA: removed Postfix tried alt2.aspmx.l.google.com and was able to deliver the non-delivery notification message EF978305D5BA(delivery status notification for B9A1C305D596). If you are interested in the content of that message, you might find it in the mailbox for en-devo-bounce+<deleted>=icloud.com > Two things caught my eye here: > * Please note the message is being sent from=<> (qmgr). This is > likely the cause of the SPF failure as there is no domain that can be > used to lookup the SPF record. Isn't SPF supposed to apply policy to the EHLO/HELO argument? Especially when the sender address has no domain. > * The goal for the past period of time is to get a look at the > headers of this message. Unfortunately the message is not being sent > to bounce-local. No entry from process "local" above to send the > message to the bounce-local user's mailbox. Message EF978305D5BA is a non-delivery notification. It has sender address <> and is a "single bounce". I contains an attachment with the headers of message B9A1C305D596 that you want to see. It was delivered to the mailbox for en-devo-bounce+<deleted>=icloud.com If for some reason you cannot access the above message with the headers of message B9A1C305D596, then you can receive a message with a copy of those headers by configuring in Postfix main.cf: notify_classes = bounce, resource, software This message has a double-bounce sender address, and is by default sent to postmaster. You can change that with: bounce_notice_recipient = bounce-local Or something else, if you prefer. HOWEVER the bounce daemon does not log the queue ID of that message, and "collate" can't tell you wat the queue was. But, assuming that double-bounce messages will be rare, you should have no difficulty finding them in the logs. Wietse _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
