Re: [mailop] Is forwarding to Gmail basically dead?
Good morning everyone, On Thu, 2024-02-08 at 13:37 +0900, Byunghee HWANG (황병희) via mailop wrote: > Hellow Jarland, > > 2-07 at 20:51 -0600, Jarland Donnell via mailop wrote: > > (...) > > Is it time to throw in the towel on email forwarding? Nearly 100% > > of > > users who forward email do so because they want it in Gmail. (...) > > How about this? > https://gitlab.com/soyeomul/stuff/-/raw/7a68692f2a6f7c5b03f7a5fa04bb79167c04cab2/82963489e8bbeb08644aeba29f722...@mxroute.com > For the record, i attach server log while forwarding... Feb 8 03:02:35 yw-1204 postfix/smtpd[38197]: connect from yw- 0919.doraji.xyz[2600:1900:4000:af49:0:3::] Feb 8 03:02:35 yw-1204 postfix/smtpd[38197]: Trusted TLS connection established from yw-0919.doraji.xyz[2600:1900:4000:af49:0:3::]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X 25519 server-signature RSA-PSS (2048 bits) client-signature RSA-PSS (2048 bits) Feb 8 03:02:36 yw-1204 postfix/smtpd[38197]: 28E65217: client=yw- 0919.doraji.xyz[2600:1900:4000:af49:0:3::] Feb 8 03:02:36 yw-1204 postfix/cleanup[38200]: 28E65217: message- id=<82963489e8bbeb08644aeba29f722...@mxroute.com> Feb 8 03:02:36 yw-1204 opendkim[647]: RFC2822.From: Jarland Donnell via mailop Feb 8 03:02:36 yw-1204 opendkim[647]: RFC2822.Reply-To: jarl...@mxroute.com Feb 8 03:02:36 yw-1204 opendkim[647]: RFC2821.MailFrom: mailop-boun...@mailop.org Feb 8 03:02:36 yw-1204 opendkim[647]: RFC2821.ORCPT: soyeomul+...@gmail.com Feb 8 03:02:36 yw-1204 opendkim[647]: RFC2822.RCVD-1: from filter006.mxroute.com ([136.175.111.2] filter006.mxroute.com)#012 (Authenticated sender: mN4UYu2MZsgR)#012 by mail-108-mta73.mxroute.com (ZoneMTA ) with ESMTPSA id 18d86a07387466.001#012 for #012 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);#012 Thu, 08 Feb 2024 02:51:18 + Feb 8 03:02:36 yw-1204 opendkim[647]: RFC5598.ADMD (Best Guess): mailop.org Feb 8 03:02:36 yw-1204 opendkim[647]: 28E65217: DKIM-Signature field added (s=yw-1204-doraji-xyz, d=doraji.xyz) Feb 8 03:02:36 yw-1204 opendkim[647]: 28E65217: DKIM-Signature field added (s=YW, d=doraji.xyz) Feb 8 03:02:36 yw-1204 postfix/qmgr[29723]: 28E65217: from=, size=5812, nrcpt=1 (queue active) Feb 8 03:02:36 yw-1204 postfix/smtpd[38197]: disconnect from yw- 0919.doraji.xyz[2600:1900:4000:af49:0:3::] ehlo=2 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7 Feb 8 03:02:36 yw-1204 postfix/smtp[38201]: Verified TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:400c:c00::1a]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exch ange X25519 server-signature ECDSA (P-256) server-digest SHA256 Feb 8 03:02:37 yw-1204 postfix/smtp[38201]: 28E65217: to=, relay=gmail-smtp- in.l.google.com[2a00:1450:400c:c00::1a]:25, delay=0.86, delays=0.26/0.02/0.32/0.27, dsn=2.0.0, status=se nt (250 2.0.0 OK 1707361357 l9-20020a05600c4f0900b0040fdd32af73si137461wmq.225 - gsmtp) Feb 8 03:02:37 yw-1204 postfix/qmgr[29723]: 28E65217: removed Forwarder's duties are: (1) Delivering to Gmail without failure. (2) Preserving the RFC2822.From header as is. So DKIM(+ARC for big ESPs) is best solution, i think. More screenshot, here: (DMARC p=REJECT email with forwarding) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1043539#93 Sincerely, Byunghee -- ^고맙습니다 _布德天下_ 감사합니다_^))// ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Why is mail forwarding such a mess?
Remember when we had an SMTP status code 551? 551 User not local; please try Pepperidge Farm remembers. SCNR, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] WKBI, was Why is mail forwarding such a mess?
It appears that Hal Murray via mailop said: > >I expect that there would be a protocol to handle it. I can't be the only one >who has thought of this. After a handshke to set things up, the sender adds a >forwarding header and the receiver verifies that a forwarded message is coming >from an allowed IP Address then bypasses spam checking for that message. (but >not phish/malware checking???) For your particular thing, I once asked someone from Google why they don't just whitelist mailing lists since they know where the lists are. They told me that the problem is that many lists do lousy filtering and all the time a real list will start leaking spam because someone's sending forged mail through it. So the point of ARC is to include enough info that the later recipient can do the filtering that the list didn't. For a likely example, it could allow messages that were DMARC aligned on the way into the list but not ones that weren't. There have been a lot of variations on that theme. I had a proposal for a "weak" DKIM signature that would usually be just on the From and Date and Message-ID headers, which is only valid if there is also a regular signature from a domain that the weak signature identifies. So you'd put your own weak signature which depended on a regular signature from the list: https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ Technically it could have worked but it'd be impossible to use since your DKIM signer would need a huge table of which destinations are lists and what signatures they'd use. R's, John ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail blocking
My suggestion is make sure you've got your ducks in a row then reach out to Google via the bulk sender form. 1. Implement DKIM and SPF. Must have both. Don't let clients send using any domain but a fully authenticated one. 2. Make sure you're not blindly sending, allowing to send, or forwarding spam. Generic old school forwarding is bad news. It tends to suck up spam, even at small levels, and screw up YOUR reputation as the forwarder. A longer discussion is likely merited if you really want to do email forwarding. 3. Implement DMARC and monitoring, make sure your poor rep isn't due to somebody else's spoofing. 4. Review Yahoo/Gmail's recent sender requirement additions and make sure you're generally able to comply. Nobody's going to expect you to add an unsub to 1:1 mail, so you'll have to apply a little logic to figure out what should apply to you and what should not, since some of the guidance is oriented to bulk/broadcast/newsletter senders. 5. Request remediation/reconsideration here: https://support.google.com/mail/contact/gmail_bulk_sender_escalation It is not impossible for small sites to deliver mail to Gmail. I've got my own personal MTA, run my own mailing lists, send my email newsletter, etc., from it, and I don't really ever have Gmail issues. But I've perhaps got an advantage of working in the deliverability space and being on top of this sort of thing for a number of years. Bonus points, don't send over IPv6 to Gmail (it's doable, but it's even more "expert level" than IPv4, historically), and make sure you've got TLS in place. That error message, though, makes it sounds like IP reputation which is a rare error. Really makes me wonder if you've got clients with custom domains potentially doing low levels of cold emailing or just unauthenticated mail that isn't getting much response from Gmail users. Read more about the Yahoo/Google changes here: https://blog.google/products/gmail/gmail-security-authentication-spam-protection/ https://blog.postmaster.yahooinc.com/post/730172167494483968/more-secure-less-spam Good luck! Cheers, Al Iverson On Thu, Feb 8, 2024 at 5:53 PM Trey Nolen via mailop wrote: > > I work with a small regional ISP and our main domain has been getting > blocked by Gmail since February 6. Our logs indicate we haven't sent a > huge volume of data to Google or anything. Our reputation has been > really good in Postmaster Tools until the 6th when it went straight to > the bottom. We never saw any indication of compromised accounts or > anything. > > We've been watching and waiting for it to clear up, but it hasn't. Other > domains can send through our system, but internetpro.net cannot. I was > hoping someone here might be from Google and could take a look. Even > the reports under Postmaster Tools look wrong as we have a 100% delivery > error rate, but all of the "Error Types" show 0.0%. > > Here is a sample of what we're seeing: > > > ---BEGIN > > 74.125.138.26 failed after I sent the message. > Remote host said: 550-5.7.1 [74.252.14.252 7] Gmail has detected > that this message is likely > 550-5.7.1 unsolicited mail. To reduce the amount of spam sent to Gmail, this > 550-5.7.1 message has been blocked. For more information, go to > 550 5.7.1 https://support.google.com/mail/?p=UnsolicitedMessageError > o20-20020a81de5400b006041f08d2dfsi1515206ywl.160 - gsmt > > ---END > > This seems to indicate that it is content filtering, but no matter what > content the messages hold, we get the same. > > > > Even if someone wanted to reach out off list, that would be great. > > > -- > Trey Nolen > supp...@internetpro.net > > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at https://www.spamresource.com Subscribe to the weekly newsletter at https://ml.spamresource.com DNS Tools: https://xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Why is mail forwarding such a mess?
>>To me this seems "fairer" than wrapping the message alone, because the >>forwarding server now takes on the burden of the reputation hit for that >>message. >>Eventually, enough viagra messages will be forwarded that the >>forwarder can't get any mail delivered anywhere. That’s on the responsibility of the receiver, to not "report as spam" in their final mailbox, but in their forwarding account. After all, its they that configured the forwarding server to forward email to their account. Its correct that the forwarder takes the responsibility of the forwarded message, as it should be. Note that a forwarding server doesn't forward to anything else than local accounts with a external redirect configured, meaning they will not become a "open relay" and become a spam problem itself. So everyone "behind" the forwarder should expect the mail. That’s the whole point of wrapping or rewriting, taking over the complete responsibility for the message so no SPF, DKIM or DMARC alignments fails. The forwarder can also do their own spam filtering on incoming messages before forwarding them to a user that has a forward configured, to prevent tripping any automatic spam reputation systems at the receiver. If a forwarder forwards a email to a mailbox for which it has no authority over, the forwarder is bad and deserves bad reputation, unless the forwarder received implicit opt-in, for example, by a user being a employee or member of some group list or similar, or if the user has a implicit trust. (some "incorrect forwards" are just human mistakes and easy to resolve once that user complains of receiving for example employee-only internal "news" email for some company, then they will ask why they get that and "ooh, that employee has a incorrect email set up, ill fix that"). ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Why is mail forwarding such a mess?
You have a good point in that the first and main problem is that the forwarder cannot be trusted to not mangle or fake the original message. Nothing else can be sorted out until this gets out of the way, including OOB communication between originator and final receiver. Which is in effect message authentication. For which we already have DKIM (among others). We could mandate DKIM for all originating SMTP servers and "forward as attachment" forwarding+DKIM for all forwarding servers. Thus, any seemingly forwarded message without its own DKIM signature and fully-wrapped DKIM-passing original is a lie (like the pie). So, my take is: lean much more on DKIM and by extension DMARC until nobody can send unauthenticated emails effectively, at all. Any $20 web/mail host has cpanel, etc that does this automatically. In the user UI nothing much will change, nor what we are currently doing at a basic level. To me this seems "fairer" than wrapping the message alone, because the forwarding server now takes on the burden of the reputation hit for that message. Eventually, enough viagra messages will be forwarded that the forwarder can't get any mail delivered anywhere. I would simply disallow forwarding rather than risk everything on the content of my user's incoming mail. They can't help it if their email has been harvested by spammers/phishers so it's an inevitability. Best Regards, George Miliotis [of the decimated small/tiny mail server brigade] ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Why is mail forwarding such a mess?
If it helps... 1. We have trained our Zimbra users who want their email to be copied someplace else to configure the someplace else to log in and collect their email from Zimbra, after having educated them that Forwarding is problematic and can get their domain blocklisted. 2. Periodically we run a script to identify accounts that have Forwarding enabled to non-Zimbra (i.e. outside) accounts and have the same training conversation with the identified users, explaining that we will be turning that Forwarding off shortly. 3. Zimbra's web client has a nifty "Edit As New" option that, instead of Forwarding an email, copies the entire body of the email thread into a newly-composed email. Once we train users to do this instead of Forwarding, everyone is much calmer and they notice their Deliverability improves. This Edit As New feature is very helpful for one customer running a unique B2B services availability business for example. They are able to receive a notice of availability from a service provider, click "Edit As New" and send the notice to their own customers to see if any of their customers are interested in booking that availability. They used to do this via Forwarding, but no longer, and it seems to be working well for them as they are no longer getting "How come you didn't tell us about that availability last week?" complaints, (when in fact the complainer's ESP either blocked the email or put it in the recipient's Junk folder, because... Forwarding). To be fair, for years we have required our hosting customers to deploy meaningful SPF and DMARC records, and to do DKIM signing, all within 30 days' of onboarding, so we haven't had much in the way of resistance from our customers as regards not using Forwarding to external accounts. We appreciate that our mostly B2B customer base generally has a more enlightened (if that's the right word...) approach to email in general, so your customer education process around Forwarding may not be as easy as our conversations were with our customers. Best regards to all, Mark _ L. Mark Stone, Founder North America's Leading Zimbra VAR/BSP/Training Partner For Companies With Mission-Critical Email Needs - Original Message - From: "Archange via mailop" To: "Hal Murray" , "Hal Murray via mailop" , "Marco Moock" Cc: "mailop" Sent: Saturday, February 10, 2024 7:10:19 AM Subject: Re: [mailop] Why is mail forwarding such a mess? Le 10 février 2024 15:12:29 GMT+04:00, Hal Murray via mailop a écrit : > >m...@dorfdsl.de said: >> Bypassing spam checking would make spammers use exactly that way to send >> spam. > >Sorry I wasn't clear enough. > >My "handshke to set things up" was meant to keep out spammers. > >The idea was that the final receiving MTA would know that it was expecting >forwarded mail for user@domain from a set of IP addresses. > >I was picturing something like: > user goes to final MTA and says I want you to accept forwarded mail for me >from example.com > then he goes to example.com and says "please forward my mail to > m...@final.com" >example.com would then contact final.com and say "OK if I forward me's mail to >you?" >If yes, then example.com says "Here are the IP addresses I use for >forwarding" I had a similar idea but much more simple: we just keep the part where the user says to the final MTA with which they have u...@domain.org that they are “forwading from m...@forwarder.org”. Then, when receiving an email SRS rewritten from forwarder.org to that u...@domain.org, the final MTA could check DKIM against the original domain but SPF and ARC against the forwarder domain since it is expecting mail to be forwarded that way for that user. Kind of a new domain alignment. No need to tell the forwarding IP, they are provided by SPF for the forwarding domain. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Why is mail forwarding such a mess?
Le 10 février 2024 15:12:29 GMT+04:00, Hal Murray via mailop a écrit : > >m...@dorfdsl.de said: >> Bypassing spam checking would make spammers use exactly that way to send >> spam. > >Sorry I wasn't clear enough. > >My "handshke to set things up" was meant to keep out spammers. > >The idea was that the final receiving MTA would know that it was expecting >forwarded mail for user@domain from a set of IP addresses. > >I was picturing something like: > user goes to final MTA and says I want you to accept forwarded mail for me >from example.com > then he goes to example.com and says "please forward my mail to > m...@final.com" >example.com would then contact final.com and say "OK if I forward me's mail to >you?" >If yes, then example.com says "Here are the IP addresses I use for >forwarding" I had a similar idea but much more simple: we just keep the part where the user says to the final MTA with which they have u...@domain.org that they are “forwading from m...@forwarder.org”. Then, when receiving an email SRS rewritten from forwarder.org to that u...@domain.org, the final MTA could check DKIM against the original domain but SPF and ARC against the forwarder domain since it is expecting mail to be forwarded that way for that user. Kind of a new domain alignment. No need to tell the forwarding IP, they are provided by SPF for the forwarding domain. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Why is mail forwarding such a mess?
m...@dorfdsl.de said: > Bypassing spam checking would make spammers use exactly that way to send > spam. Sorry I wasn't clear enough. My "handshke to set things up" was meant to keep out spammers. The idea was that the final receiving MTA would know that it was expecting forwarded mail for user@domain from a set of IP addresses. I was picturing something like: user goes to final MTA and says I want you to accept forwarded mail for me from example.com then he goes to example.com and says "please forward my mail to m...@final.com" example.com would then contact final.com and say "OK if I forward me's mail to you?" If yes, then example.com says "Here are the IP addresses I use for forwarding" -- These are my opinions. I hate spam. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
Hello Sebastian, On 10.02.24 05:02, Sebastian Nielsen via mailop wrote: just because SPF and DMARC are so badly designed that they can't handle it doesnt make it "forging" anything. It isn't badly designed. Forwarding a email, is the equvalient of, when you receive a signed envelope from me containing a letter, you forge my signature on the new envelope. It's actually the equivalent of striking through the recipient, writing a new one on the envelope and putting it back into the mailbox. This is a quite common behavior if people have moved for example. Regards, Thomas Walter -- Thomas Walter Datenverarbeitungszentrale FH Münster - University of Applied Sciences - Corrensstr. 25, Raum B 112 48149 Münster Tel: +49 251 83 64 908 Fax: +49 251 83 64 910 www.fh-muenster.de/dvz/ smime.p7s Description: S/MIME Cryptographic Signature ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
John Levine via mailop skrev den 2024-02-10 05:25: PS: Perhaps this list needs a FAQ of Well Known Bad Ideas so we can stop having this argument over and over. or make mailman patch that stops mailman from breaking dkim ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
John Levine via mailop skrev den 2024-02-10 05:22: It appears that Sebastian Nielsen via mailop said: just because SPF and DMARC are so badly designed that they can't handle it doesnt make it "forging" anything. It isn't badly designed. Forwarding a email, is the equvalient of, when you receive a signed envelope from me containing a letter, you forge my signature on the new envelope. Sorry, but repeating this doesn't make this any less wrong. +1 I don't know what you imagine "signed envelope" means in this context and I'm not sure I want to know. means dkim signed envelope, that breaks if not using srs ? The postal equivalent of forwarding is forwarding, you write the person's new address on the envelope and drop it back in the mail. It has the same return address because it's the same letter. +1 People have been making this victim-blaming argument for 20 years, ever since SPF was designed in a way that failed to handle normal forwarding. when envelope sender domain changes, its a new spf domain to take responsible of spf, but this will forever be unaligned results on dmarc It was silly then, and it's no less silly now. lets make more books on it :=) This is my last comment on the topic, at least for this round. we could join another maillist that does not break dkim, in 2024 its gone more sadly :/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Is forwarding to Gmail basically dead?
Sebastian Nielsen via mailop skrev den 2024-02-10 05:11: And also as a side note, this list server (mailop) also does sender rewriting to From: mailop@mailop.org to prevent SPF and DMARC from tripping on list mail. So its obvious it’s the right way to do it. Same have the list "Exim-Users" begun to do. stop breaking dkim, stop just stop say spf is a problem for unaligned mails, its not right gun to take you writed dmarc, so i reply on it, i just hope on a better world ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
