Re: [mailop] Gmail spam scoring via IPv6 different than IPv4?
On Fri, Aug 12, 2022 at 3:15 PM Simon Arlott via mailop wrote: > On 12/08/2022 17:22, Jesse Hathaway via mailop wrote: > > Back in 2013[1] we changed our mail config to force MX lookups for gmail > > to only use IPv4 addresses. We made these change after hearing reports > > of higher spam scoring when sending mail via IPv6. Would anyone from > > Google be able to comment as to whether forcing IPv4 is still needed? > > Yours kindly, Jesse Hathaway > > My experience in the past is that because Google insist on a successful > matching reverse DNS lookup for IPv6, it will randomly permanently > reject email for a temporary error. It looks like Google are now doing > this for IPv4 too but I don't know if they've fixed it to handle > temporary DNS errors properly. > > The other general problem is that your server's reputation will probably > be different for each address and suddenly swap between IPv6 and IPv4 on > a retry. Ideally random outgoing address selection across all IP address > families should be used to avoid this but Exim can't do that. > While we try to do the right thing with DNS temp failures, it can be challenging to differentiate sometimes. We would also need to propagate a dns temp failure into an spf/etc temp failure and then potentially have different spam rejects based on whether a specific spam rule depended on those features... but that's not really how the spam system works. And yes, while we started with stricter auth requirements for IPv6, that's coming for IPv4 incrementally. That said, fundamentally an IPv6 address is different from an IPv4 one, which means different netblocks as well, and different reputations. Unless you split your mail evenly between them, and had the same mail stream evenly split across the entire netblock... and ASN... you wouldn't have identical spam results. Brandon ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail spam scoring via IPv6 different than IPv4?
I mean, you can either limit it to the limits in the RFC and fail a bunch of things that would otherwise pass, or acknowledge that those limits are much smaller than practical given the proliferation of third party senders that are used by companies. Especially since some larger companies will not break the limit themselves, but make it much harder for their users to stay within the limits (ugh, yeah, that's workspace customers). Brandon On Fri, Aug 12, 2022 at 10:59 AM Michael Peddemors via mailop < mailop@mailop.org> wrote: > Addendum: It's amazing how many billion dollar companies can't even get > SPF right.. Pop Quiz.. how many recursive DNS queries are supposed to be > in SPF max? > > On 2022-08-12 10:24, Michael Peddemors via mailop wrote: > > And frankly, for most people it is the easiest solution. > > > > So many time we tell people, turn off IPv6 and all their problems go > > away, but asking them to set up all the extra layers such as SPF, DKIM > > etc, and to do it right.. well.. in practice, people have better things > > to do.. > > > > We of course still say: > > > > * Sane PTR, only a single one unless you are forced to have two (small > > subnet DNS responsibility) > > * Only a couple of A records, keep the list small (UDP vs retry to TCP0 > > * Implement a sane SPF record (Amazing how many people have trouble with > > this, or simply add everyone.. if you include all of google, amazon, and > > microsoft, why bother having an SPF record ;) > > * Turn off ipv6 for MTA->MTA mail. (I know the IPv6 evangelists scream > > when I say this, but email operators just want it to work) Slowly we > > work towards first MTU->MTA over IPv6, I think we will see IPv4->IPv4 > > for server to server communication for some time yet. > > > > Let's not try to make it too difficult for the little guys, we should be > > encouraging more people operating email servers, not making it so > > difficult that they throw their hands in the air, and move to Gmail.. > > (of course, that might be the plan all along ;) > > > > On 2022-08-12 09:47, Al Iverson via mailop wrote: > >> Hey Jesse, > >> > >> This is sort of controversial and you'll get some people saying very > >> vehemently that you should never do this ever, for various reasons of > >> interoperability or strong opinions about how the internet works. But > >> instead, here's my take from an operational perspective... > >> > >> I personally would keep forcing mail to Gmail over IPv4, and I do > >> indeed do this on my own hobbyist systems. Every time I spin up a new > >> VPS and forget this, I notice it rather quickly because of bouncing > >> mail. Not only are they quicker to block IPv6 mail overall (IMHO), > >> they also are more likely to block IPv6 mail from IPs without rDNS, > >> and mail that lacks either SPF or DKIM authentication. Their filters > >> are evolving and it feels as though their IPv4 blocking is catching up > >> a bit -- more likely to block unauthenticated IPv4 mail today versus a > >> year or two ago, but that doesn't really mean it suddenly became > >> easier to send over IPv6. > >> > >> I blogged about this a couple year ago - nothing you don't already > >> know, really - > >> > https://www.spamresource.com/2020/11/honestly-dont-send-to-gmail-over-ipv6.html > >> > >> - but recently that article got linked to on Reddit and a bunch of > >> nerds made noise that I don't know what I'm talking about and that > >> they can get mail to Gmail over IPv6 just fine. So, YMMV. (My point is > >> that it's not impossible, but it is annoying and that it has exacting, > >> but unclear requirements.) > >> > >> Cheers, > >> Al Iverson > >> > >> On Fri, Aug 12, 2022 at 11:26 AM Jesse Hathaway via mailop > >> wrote: > >>> > >>> Back in 2013[1] we changed our mail config to force MX lookups for > gmail > >>> to only use IPv4 addresses. We made these change after hearing reports > >>> of higher spam scoring when sending mail via IPv6. Would anyone from > >>> Google be able to comment as to whether forcing IPv4 is still needed? > >>> Yours kindly, Jesse Hathaway > >>> > >>> > >>> [1]: https://gerrit.wikimedia.org/r/c/operations/puppet/+/79753 > >>> ___ > >>> mailop mailing list > >>> mailop@mailop.org > >>> https://list.mailop.org/listinfo/mailop > >> > >> > >> > > > > > > > > > > -- > "Catch the Magic of Linux..." > > Michael Peddemors, President/CEO LinuxMagic Inc. > Visit us at http://www.linuxmagic.com @linuxmagic > A Wizard IT Company - For More Info http://www.wizard.ca > "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. > > 604-682-0300 <(604)%20682-0300> Beautiful British Columbia, Canada > > This email and any electronic data contained are confidential and intended > solely for the use of the individual or entity to which they are addressed
Re: [mailop] [E] Re: Gmail Dynamic Email / Impact on Email Ecosystem
"Just links" is of course the potential fall back for both of these, clearly confidential emails can't be implemented with actual email, and short of something like message/external-body is unlikely to be multi-client (especially since the sender would want to control the controls on the content, not trusting the client to implement them). It turns out, presenting the content in-line is very useful compared to requiring users to click away. Brandon On Fri, Aug 12, 2022 at 1:46 AM Taavi Eomäe via mailop wrote: > > Yeah, just like any website can "change". I encourage you to dive a > > little deeper into the capabilities (and non-capabilities) for that > > matter ;-) > > Sure, and those of us who have had to deal with taking down phishing > that is very selective know the pain. That pain shouldn't exist in > emails themselves. Taking Gmail's other feature as well, confidential > emails. YIKES > > Imagine this scenario: > "I got this letter, it looks very suspicious" > "Can you forward it to me?" > "I can't it won't let me, says something about being marked confidential" > "Okay just show it to me then" > "I opened it again and it has changed" > > > No. Not the MTA anyway. > > It depends where you're doing your filtering. > > > Yes, and horses are sufficiently fast and 64kb ought to be enough for > > everybody ;-) > > Just send links if you need to display dynamic content, that's what > links are for. Alternatively implement a diff scheme that would allow > building the end result. Messages already delivered shouldn't change > without either clear indication or user preference that they may. > > Even though I loathe "you just got a reply to your comment"-emails, > they're better than ones I might open years from now, potentially broken. > > ___ > 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] Gmail Dynamic Email / Impact on Email Ecosystem
On Thu, Aug 11, 2022 at 4:09 PM Ángel via mailop wrote: > On 2022-08-11 at 10:55 +, Gellner, Oliver wrote: > > In other MUAs they display like normal emails, Id expect that Googles > > dynamic emails behave the same way. > > They seem to be a text/x-amp-html, and require a text/html or > text/plain fallback, so other clients would simply use the fallback. > At least the design seems robust, enforcing that this new standard is s > trictly followed. > > Like Tobias, I also found about them really recently. I am not really > convinced about them so far. Not the way Google implemented them, but > the underlying concept. > I understand why an email that is kept up-to-date can be thought to > make sense in some cases, but a "dynamic email" breaks the concept of > an email that we have been using for the last fifty years. > > An email archive used to be similar to an archived physical letter in > that it is immutable. You could go back and read the same content you > viewed a few days ago. With this, you could find it now contains > something different. Even two people receiving the same email could get > shown different content. > > This was already possible to some extent by using external images, but > only as a subproduct. > > This attempt is a big change on the basics of email, and only time will > tell us if it changes things radically, or ends up discarded. > I think a lot of email consumers these days are confused by the non-static nature of email. They see something new in their inbox and expect that it's actually "recent" or "current", when in reality it was sent some time in the past which may be days or weeks. In that sense, updating the information in the email to be current has some utility... even if most of the cases I can think of may be just as easily be served by say an "expires" header or something. One can imagine a "deal" email that has now expired, or a time limited password reset email. The most common one I see (which I assume is amp but maybe is more specific google internal) is the email notifications for comment threads in google docs, which show the latest comments and not just the individual one. Frankly, since you get one for each comment, and then they're updated to all show the full list, it seems weird, but I can see that it maybe helps sometimes. Will dynamic email be useful in the long term or a dead end? I don't know. Brandon ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] I understand less and less why I accept any mail at all from Sendgrid
Honestly the difference between SendGrid and the top 10 list here seems like it's shrinking every day: https://www.spamhaus.org/statistics/spammers/ On 2022-08-15 19:42, Stuart Henderson via mailop wrote: On 2022/08/16 02:03, Ángel via mailop wrote: On 2022-08-13 at 18:46 -0400, John Levine wrote: > Subject: IP address blacklisted(Child Pornography Act 1996 violated) > > Hello, > > We have found instances of child pornography accessed from your IP > address. This is a punishable offence under The Child Pornography > Prevention Act of 1996 . For now we are blacklisting your IP address > and if there is any further action from Microsoft you will be > informed via email. > > If this was not you and you suspect potential hack or id theft > contact Microsoft Support Team at +1-808-460-7701 > > Microsoft Support > +1-808-460-7701 > > support This is probably "just" a tech support scam. I have seen others on a similar theme, but claiming to be sent from the national police and asking you to provide your allegations to an email address. Presumably in order to get replies of those gullible enough to believe it and pay a "fine" and, one would guess, hunting in case someone admitted something worth being extorted about. yes yes, but the point is that Twilio SendGrid are allowing their services to be used by whoever is sending this. With a website saying things like "We take trust and security seriously" and "With the industry’s largest team of delivery experts monitoring your sender reputation" they don't pick up on this? ___ 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] I understand less and less why I accept any mail at all from Sendgrid
On 2022/08/16 02:03, Ángel via mailop wrote: > On 2022-08-13 at 18:46 -0400, John Levine wrote: > > Subject: IP address blacklisted(Child Pornography Act 1996 violated) > > > > Hello, > > > > We have found instances of child pornography accessed from your IP > > address. This is a punishable offence under The Child Pornography > > Prevention Act of 1996 . For now we are blacklisting your IP address > > and if there is any further action from Microsoft you will be > > informed via email. > > > > If this was not you and you suspect potential hack or id theft > > contact Microsoft Support Team at +1-808-460-7701 > > > > Microsoft Support > > +1-808-460-7701 > > > > support > > This is probably "just" a tech support scam. I have seen others on a > similar theme, but claiming to be sent from the national police and > asking you to provide your allegations to an email address. Presumably > in order to get replies of those gullible enough to believe it and pay > a "fine" and, one would guess, hunting in case someone admitted > something worth being extorted about. yes yes, but the point is that Twilio SendGrid are allowing their services to be used by whoever is sending this. With a website saying things like "We take trust and security seriously" and "With the industry’s largest team of delivery experts monitoring your sender reputation" they don't pick up on this? ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] I understand less and less why I accept any mail at all from Sendgrid
On 2022-08-13 at 18:46 -0400, John Levine wrote: > Subject: IP address blacklisted(Child Pornography Act 1996 violated) > > Hello, > > We have found instances of child pornography accessed from your IP > address. This is a punishable offence under The Child Pornography > Prevention Act of 1996 . For now we are blacklisting your IP address > and if there is any further action from Microsoft you will be > informed via email. > > If this was not you and you suspect potential hack or id theft > contact Microsoft Support Team at +1-808-460-7701 > > Microsoft Support > +1-808-460-7701 > > support This is probably "just" a tech support scam. I have seen others on a similar theme, but claiming to be sent from the national police and asking you to provide your allegations to an email address. Presumably in order to get replies of those gullible enough to believe it and pay a "fine" and, one would guess, hunting in case someone admitted something worth being extorted about. Regards ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Gmail spam scoring via IPv6 different than IPv4?
Thanks everyone for the advice. For the immediate future I am going to continue to send to Gmail only over IPv4. After I have some confidence that I have checked all the boxes for our IPv6 IPs I will do some experimental sending to Gmail from those IPs. If I can achieve reliable delivery I will consider removing the IPv4 only config. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
