[mailop] Exact Target (Pardot) unsubscribe link is insecure..
Return-Path: Click on the unsubscribe link, and it goes to an insecure pardot page. -- "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 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. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Exact Target (Pardot) unsubscribe link is insecure..
On Wed, Apr 13, 2022 at 10:21:18AM -0700, Michael Peddemors via mailop wrote: > Return-Path: > > > Click on the unsubscribe link, and it goes to an insecure pardot page. Envelope-senders are not links, though. -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] Exact Target (Pardot) unsubscribe link is insecure..
This isn't Pardot or Salesforce support so I don't know what good it does to post about it here, to be honest. Pardot clients can/should implement SSL on their tracker domain (which includes the list-unsub domain): https://help.salesforce.com/s/articleView?id=000318025&type=1 I just read a blog post that implies that the default go.pardot.com domain is getting SSL added, too? Maybe? https://www.salesforceben.com/the-drip/go-pardot-com/ I don't work in Salesforce land any more, so I have no detail beyond that... Cheers, Al On Wed, Apr 13, 2022 at 12:39 PM Atro Tossavainen via mailop wrote: > > On Wed, Apr 13, 2022 at 10:21:18AM -0700, Michael Peddemors via mailop wrote: > > Return-Path: > > > > > > Click on the unsubscribe link, and it goes to an insecure pardot page. > > Envelope-senders are not links, though. > > -- > Atro Tossavainen, Chairman of the Board > Infinite Mho Oy, Helsinki, Finland > tel. +358-44-5000 600, http://www.infinitemho.fi/ > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] gmail - pop3 retrieval checking SPF ? ( gmail, wth ? Take 2 )
Hi all. Why on earth is gmail checking the IP address of the message sender (ISP assigned home address, for instance) against the sender's domain SPF without the ability of checking if that original delivery was done using SMTP authentication ( hence voiding the need for that IP being part of the SPF record ) ? Moreover, why on earth is gmail doing a SPF check ( that should ONLY be done during the smtp conversation ) during a pop3 retrieval ?! If there is anyone here from gmail ... fix that please. -- Paulo Azevedo ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] gmail - pop3 retrieval checking SPF ? ( gmail, wth ? Take 2 )
On 14/04/2022 01:02, Paulo Pinto via mailop wrote: Hi all. Why on earth is gmail checking the IP address of the message sender (ISP assigned home address, for instance) against the sender's domain SPF without the ability of checking if that original delivery was done using SMTP authentication ( hence voiding the need for that IP being part of the SPF record ) ? I know its early i morning and I;m only just now taking my first sip of coffee, but, err... this is what SPF does, checks sebder is allowed to send as XYZ, smtp authed users sender from mail server and its in senders domain, all fine there Moreover, why on earth is gmail doing a SPF check ( that should ONLY be done during the smtp conversation ) during a pop3 retrieval ?! If there is anyone here from gmail ... fix that please. That however is not fine, it should already have done the spf check, are you certain it is doing it in pop transaction or just guessing? Pasting a short snippet of your evidence might help someone take notice. -- Regards, Noel Butler This Email, including attachments, may contain legally privileged information, therefore at all times remains confidential and subject to copyright protected under international law. You may not disseminate this message without the authors express written authority to do so. If you are not the intended recipient, please notify the sender then delete all copies of this message including attachments immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message.___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] gmail - pop3 retrieval checking SPF ? ( gmail, wth ? Take 2 )
This is in fact how they do it, and it is quite objectively wrong. SPF is only useful when checking the connecting IP, but since they're not receiving the mail they miss out on that transaction. Reasonable logic would dictate that one should give up attempting to check SPF at that stage or, at the very least, become much better at reading those Received headers with automation. Google has opted for neither, and so this is a common issue. On 2022-04-13 10:02, Paulo Pinto via mailop wrote: Hi all. Why on earth is gmail checking the IP address of the message sender (ISP assigned home address, for instance) against the sender's domain SPF without the ability of checking if that original delivery was done using SMTP authentication ( hence voiding the need for that IP being part of the SPF record ) ? Moreover, why on earth is gmail doing a SPF check ( that should ONLY be done during the smtp conversation ) during a pop3 retrieval ?! If there is anyone here from gmail ... fix that please. -- Paulo Azevedo ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
[mailop] $GOOG
it's troubling me that in a recent thread asking where to host mailboxes, google was recommended several times, in spite of the fact that google is provably wrong and provably non-transarent in how they decide what inbound e-mail to reject. of all constituencies, this one, mailop, is one i would have expected to know better than to cooperate with your oppressor. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] $GOOG
On 2022-04-13 14:43, Paul Vixie via mailop wrote: it's troubling me that in a recent thread asking where to host mailboxes, google was recommended several times, in spite of the fact that google is provably wrong and provably non-transarent in how they decide what inbound e-mail to reject. of all constituencies, this one, mailop, is one i would have expected to know better than to cooperate with your oppressor. +1 .. otherwise you help make the oppressor an evil overlord.. -- "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 Beautiful British Columbia, Canada ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] $GOOG
If you find an email provider that has no opinion or detractors in relation to how to reject emails or which emails to reject, you'll find a wealth of other complaints that stem directly from this. Out of the 140,244 emails delivered to Google by my customers today, not a single one has complained of issues with Google rejecting legitimate email. On 2022-04-13 16:43, Paul Vixie via mailop wrote: it's troubling me that in a recent thread asking where to host mailboxes, google was recommended several times, in spite of the fact that google is provably wrong and provably non-transarent in how they decide what inbound e-mail to reject. of all constituencies, this one, mailop, is one i would have expected to know better than to cooperate with your oppressor. ___ 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] $GOOG
heho, thanks for bringing this up. i am currently digging a bit in the whole scape of centralization, especially in academia (see page 4-7 here for the perspective of mail-hosting in academia: https://arxiv.org/pdf/2104.09462.pdf ); things are... dire, especially in the us. universities used to be _the_ place self-hosting infrastructure. email is a rather evolving system, and to align the design choices of the past with the needs of a mass Internet, the complexity of running stuff oneself is going up (and the number of dmarc report rua bounces from _large_ entities i get each night tells me that this is not limited to smaller operators...); with major providers intransparently deciding what to enforce (and what applies to them), i hear many saying 'well, if you want your mails delivered, go for $bigone'. this is essentially how we lost xmpp and i fear the dice are already in the cup for smtp et al. (and the rest of the Internet). with best regards, tobias -Original Message- From: mailop On Behalf Of Paul Vixie via mailop Sent: Wednesday, 13 April 2022 23:44 To: mailop@mailop.org Subject: [mailop] $GOOG it's troubling me that in a recent thread asking where to host mailboxes, google was recommended several times, in spite of the fact that google is provably wrong and provably non-transarent in how they decide what inbound e-mail to reject. of all constituencies, this one, mailop, is one i would have expected to know better than to cooperate with your oppressor. ___ 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] $GOOG
On 4/13/2022 6:58 PM, Jarland Donnell via mailop wrote: Out of the 140,244 emails delivered to Google by my customers today, not a single one has complained of issues with Google rejecting legitimate email. Even so, keep in mind the following: (1) Their most egregious false positives - ARE delivered - they return a "250 OK" response - but then Google's spam filter does a 2nd round of spam filtering - AFTER the SMTP connection has completed - and that's where MOST of their most egregious false positives occur - partly because the sender THINKS that their message was delivered. (2) These are OFTEN the types of mistakes that are most often unknown to the sender - since the sender then never gets back a non-delivery notification. (and unfortunately not everyone is savvy and consistent with requesting and monitoring for "read receipts" for important hand-typed emails!) So then they don't "complain" to their mail hoster about a problem they don't even know exists! (so their lack of "complaints" is an inadequate/flawed measurement of success in this case!) For example, I have a close relative who was the CFO of a company a couple of years ago (with hundreds of millions in annual sales) - before he switched to another company - and what I'm about to describe occurred AFTER Google's huge move to going "all in" on A.I. for email processing - and so this company almost lost the renewal of a multi-million dollar deal because their client's hand-typed messages were getting 250 OK answers, but were spam-filtered after-the-fact by Google. The client thought that they were getting dissed by their vendor - since they didn't get non-delivered notifications for those emails - and so this client was already in the process of looking for a new vendor when someone at my relative's (former) company spotted the false positives from this client in the spam folder at the last "final hour" and just barely saved the deal. Of course, that's anecdotal and ALL spam filters have occasional egregious false positives. But it's just that your "delivered to Google" might not mean as much as you thought that it meant! It's possible that a few of those 140,244 emails might not have made it to the inbox! -- Rob McEwen, invaluement ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] [E] $GOOG
On Wed, Apr 13, 2022 at 2:58 PM Paul Vixie via mailop wrote: > that google is provably wrong and provably non-transarent in how they > decide what inbound e-mail to reject. > Unless you have a solution which ensures that only good senders are able to send email, then yes, you will find that receivers will be mostly non-transparent on how they decide what to reject. Any receiver protecting their users will be. > know better than to cooperate with your oppressor. > This was stressed before (even by the list admin): But if you want people to collaborate and be more transparent, maybe refrain from sentences like the one above. - Marcel ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] $GOOG
If you can take the activist hat off and think like an average person with average objectives, Google is the right answer. There is nothing wrong with suggesting this. There are pros and cons. As a grown up, I understand that everything is a trade off. But for most people, Google is the right answer here. Luke On Wed, Apr 13, 2022, 3:33 PM Michael Peddemors via mailop < mailop@mailop.org> wrote: > On 2022-04-13 14:43, Paul Vixie via mailop wrote: > > it's troubling me that in a recent thread asking where to host > > mailboxes, google was recommended several times, in spite of the fact > > that google is provably wrong and provably non-transarent in how they > > decide what inbound e-mail to reject. > > > > of all constituencies, this one, mailop, is one i would have expected to > > know better than to cooperate with your oppressor. > > +1 .. otherwise you help make the oppressor an evil overlord.. > > -- > "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 Beautiful British Columbia, Canada > > ___ > 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] $GOOG
I've seen Microsoft do that very thing many times over the years, accepting an email but never delivering it. I have to admit, I have not once witnessed this with Gmail. Given how much volume we do where customers bring their own domains, I would find it strange to have not run into it, if it is an actual issue that occurs. Filtering to the spam folder of course happens with email that received a 2xx, but I've not yet seen a blackhole. I would be interested in hearing more about it if anyone has collected any data around it. On 2022-04-13 19:28, Rob McEwen via mailop wrote: On 4/13/2022 6:58 PM, Jarland Donnell via mailop wrote: Out of the 140,244 emails delivered to Google by my customers today, not a single one has complained of issues with Google rejecting legitimate email. Even so, keep in mind the following: (1) Their most egregious false positives - ARE delivered - they return a "250 OK" response - but then Google's spam filter does a 2nd round of spam filtering - AFTER the SMTP connection has completed - and that's where MOST of their most egregious false positives occur - partly because the sender THINKS that their message was delivered. (2) These are OFTEN the types of mistakes that are most often unknown to the sender - since the sender then never gets back a non-delivery notification. (and unfortunately not everyone is savvy and consistent with requesting and monitoring for "read receipts" for important hand-typed emails!) So then they don't "complain" to their mail hoster about a problem they don't even know exists! (so their lack of "complaints" is an inadequate/flawed measurement of success in this case!) For example, I have a close relative who was the CFO of a company a couple of years ago (with hundreds of millions in annual sales) - before he switched to another company - and what I'm about to describe occurred AFTER Google's huge move to going "all in" on A.I. for email processing - and so this company almost lost the renewal of a multi-million dollar deal because their client's hand-typed messages were getting 250 OK answers, but were spam-filtered after-the-fact by Google. The client thought that they were getting dissed by their vendor - since they didn't get non-delivered notifications for those emails - and so this client was already in the process of looking for a new vendor when someone at my relative's (former) company spotted the false positives from this client in the spam folder at the last "final hour" and just barely saved the deal. Of course, that's anecdotal and ALL spam filters have occasional egregious false positives. But it's just that your "delivered to Google" might not mean as much as you thought that it meant! It's possible that a few of those 140,244 emails might not have made it to the inbox! -- Rob McEwen, invaluement ___ 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] [E] $GOOG
>> that google is provably wrong and provably non-transarent in how they >> decide what inbound e-mail to reject. > > Unless you have a solution which ensures that only good senders are able to > send email, then yes, you will find that receivers will be mostly > non-transparent on how they decide what to reject. Any receiver protecting > their users will be. > >> know better than to cooperate with your oppressor. > > This was stressed before (even by the list admin): But if you want people to > collaborate and be more transparent, maybe refrain from sentences like the > one above. Seconded. Google does not do things the way I would, and I find them frustrating, yes, but no, it is not true about there being some conspiracy to keep you out, and no, it's not unfixable, unless you stick your head in the sand or put your fingers in your ears and don't do things the right way for 2022 because you don't want to or can't. Cheers, Al Iverson -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] $GOOG
I've seen it happen perhaps twice in twenty years, from what I can non-scientifically recall. 99.9% of the time we've had somebody complain they can't find the mail in their Gmail account, it is because it's in their spam folder. I'm not particularly worried that there's some new outbreak of this. Even back in the day, unexpected internal delays inside of Gmail were more common, and even those were relatively rare. To your point, yeah, Microsoft used to be the big bad who would discard mail after accepting it and that was a super huge pain to deal with. That seems to be a thing of the past, thankfully. Cheers, Al Iverson On Wed, Apr 13, 2022 at 7:59 PM Jarland Donnell via mailop wrote: > > I've seen Microsoft do that very thing many times over the years, > accepting an email but never delivering it. I have to admit, I have not > once witnessed this with Gmail. Given how much volume we do where > customers bring their own domains, I would find it strange to have not > run into it, if it is an actual issue that occurs. > > Filtering to the spam folder of course happens with email that received > a 2xx, but I've not yet seen a blackhole. I would be interested in > hearing more about it if anyone has collected any data around it. > > On 2022-04-13 19:28, Rob McEwen via mailop wrote: > > On 4/13/2022 6:58 PM, Jarland Donnell via mailop wrote: > > > >> Out of the 140,244 emails delivered to Google by my customers today, > >> not a single one has complained of issues with Google rejecting > >> legitimate email. > > > > Even so, keep in mind the following: > > > > (1) Their most egregious false positives - ARE delivered - they return > > a "250 OK" response - but then Google's spam filter does a 2nd round > > of spam filtering - AFTER the SMTP connection has completed - and > > that's where MOST of their most egregious false positives occur - > > partly because the sender THINKS that their message was delivered. > > > > (2) These are OFTEN the types of mistakes that are most often unknown > > to the sender - since the sender then never gets back a non-delivery > > notification. (and unfortunately not everyone is savvy and consistent > > with requesting and monitoring for "read receipts" for important > > hand-typed emails!) So then they don't "complain" to their mail hoster > > about a problem they don't even know exists! (so their lack of > > "complaints" is an inadequate/flawed measurement of success in this > > case!) > > > > For example, I have a close relative who was the CFO of a company a > > couple of years ago (with hundreds of millions in annual sales) - > > before he switched to another company - and what I'm about to describe > > occurred AFTER Google's huge move to going "all in" on A.I. for email > > processing - and so this company almost lost the renewal of a > > multi-million dollar deal because their client's hand-typed messages > > were getting 250 OK answers, but were spam-filtered after-the-fact by > > Google. The client thought that they were getting dissed by their > > vendor - since they didn't get non-delivered notifications for those > > emails - and so this client was already in the process of looking for > > a new vendor when someone at my relative's (former) company spotted > > the false positives from this client in the spam folder at the last > > "final hour" and just barely saved the deal. > > > > Of course, that's anecdotal and ALL spam filters have occasional > > egregious false positives. But it's just that your "delivered to > > Google" might not mean as much as you thought that it meant! It's > > possible that a few of those 140,244 emails might not have made it to > > the inbox! > > > > -- > > Rob McEwen, invaluement > > ___ > > mailop mailing list > > mailop@mailop.org > > https://list.mailop.org/listinfo/mailop > ___ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop -- Al Iverson / Deliverability blogging at www.spamresource.com Subscribe to the weekly newsletter at wombatmail.com/sr.cgi DNS Tools at xnnd.com / (312) 725-0130 / Chicago (Central Time) ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] $GOOG
Al, fwiw, I've confirmed at some point within the past couple of years - directly with Brandon Long of Google - that, yes, Google does have this extra after-connection filtering, where a message can potentially be spam filtered even though the sender's mail server received a "250 OK" response. How often this happens - it's hard to say - probably in a tiny fraction of messages that they spam filter - but in my boutique hosting of a few thousand users - I've anecdotally come across this at least a few times in the past couple of years, where it was likely a false positive, but yet the sender got a "250 OK" response. That the message may have been in the recipients' google spam folder - is something I already acknowledged, but that's "besides the point". Also, while many mail hosters ALSO do this filtering technique, I consider this to /typically/ be an inferior spam filtering practice, although I'm open to the idea that doing it on a very limited basis might be OK (such as when an attachment has a /strong/ potential be a zero-day virus that anti-virus systems are not yet detecting... stuff like that). Regardless, such "250 OK" false positive being in the intended recipient's spam folder - is something I referenced in my original post, and that doesn't impact any of my points. ALSO - this reminds me - another inferior practice of some of these largest email providers - including Google - is the lack of support and willingness/ability to make changes in response to egregious filtering mistakes. IT staff of their customers are OFTEN told by these large providers - "it is what it is" - with no willingness to look into SMTP logs and figure out and fix exactly what went wrong - but level of service doesn't scale, right? (But yet they STILL charge premium prices per mailbox - so in spite of this - their REVENUE "scales"!) Slightly changing the subject and getting back to Paul Vixie's original post (the post that started this thread) about Google's lack of spam filtering transparency - unless he's referring to something bad of which I'm not aware - otherwise, I think he's being a little too picky - spam filtering is 1/2 sausage factory (if you saw it up close, you'd be shocked about how crazy it is) - and part front-lines war zone. So, in summary, spam filtering is "a sausage factory on the front lines of a war zone". Then Paul Vixie comes along and asks, "where's your TPS report?" (a reference from the movie "office space" - remember that?) - and those of us running spam filters are like "dude, we're just barely surviving, and everything is so fast paced and changing so often - we can't even think about that TPS report!" Or, in Paul Vixie's defense, maybe Paul is thinking about the fact that gmail's outbound spam has been absolutely INSANE the past several months, with no end of slowdown in sight. It's insane that this has gotten so little attention in recent months, and that Google keeps seemingly getting a free pass over that. So there's that, too. And it's bizarre that so many are so "OK" with that! (or pretend that this isn't happening?) Or - again - maybe Paul Vixie knows something that many of us don't know about - regarding Google's mail system! I wouldn't rule that out. Rob McEwen, invaluement On 4/13/2022 10:27 PM, Al Iverson via mailop wrote: I've seen it happen perhaps twice in twenty years, from what I can non-scientifically recall. 99.9% of the time we've had somebody complain they can't find the mail in their Gmail account, it is because it's in their spam folder. I'm not particularly worried that there's some new outbreak of this. Even back in the day, unexpected internal delays inside of Gmail were more common, and even those were relatively rare. To your point, yeah, Microsoft used to be the big bad who would discard mail after accepting it and that was a super huge pain to deal with. That seems to be a thing of the past, thankfully. Cheers, Al Iverson On Wed, Apr 13, 2022 at 7:59 PM Jarland Donnell via mailop wrote: I've seen Microsoft do that very thing many times over the years, accepting an email but never delivering it. I have to admit, I have not once witnessed this with Gmail. Given how much volume we do where customers bring their own domains, I would find it strange to have not run into it, if it is an actual issue that occurs. Filtering to the spam folder of course happens with email that received a 2xx, but I've not yet seen a blackhole. I would be interested in hearing more about it if anyone has collected any data around it. On 2022-04-13 19:28, Rob McEwen via mailop wrote: On 4/13/2022 6:58 PM, Jarland Donnell via mailop wrote: Out of the 140,244 emails delivered to Google by my customers today, not a single one has complained of issues with Google rejecting legitimate email. Even so, keep in mind the following: (1) Their most egregious false positives - ARE delivered - they return a "250 OK" response - but then
Re: [mailop] $GOOG
On 4/13/2022 11:32 PM, Rob McEwen wrote: Or, in Paul Vixie's defense, maybe Paul is thinking about the fact that gmail's outbound spam has been absolutely INSANE the past several months, with no end of slowdown in sight. It's insane that this has gotten so little attention in recent months, and that Google keeps seemingly getting a free pass over that. So there's that, too. And it's bizarre that so many are so "OK" with that! (or pretend that this isn't happening?) To clarify - while I don't 100% understand Paul Vixie's logic/reasoning/facts - but maybe that's due to my lack of being fully informed? - at the SAME time - I arrive at the SAME conclusion as Paul, for the reason mentioned above. No organization sending out THIS much spam - including massive amounts of spam from criminal fraudsters - should be considered a respected member of the email ecosystem - nor should be rewarded with any additional business. -- Rob McEwen, invaluement ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] gmail - pop3 retrieval checking SPF ? ( gmail, wth ? Take 2 )
On Wed, 13 Apr 2022, Paulo Pinto wrote: Why on earth is gmail checking the IP address of the message sender (ISP assigned home address, for instance) against the sender's domain SPF I've mentioned it before to which got a "I don't think we do that" when it was plain they did (their own SPF results claimed that's what they checked). Google appears to be trying to decide if it was submitted from a "bad" place thus is likely a bad message by checking SPF as if they were the initial receiver, with the same checks applying to messages they fetch from elsewhere. On the surface it seems a reasonable way to catch submissions using stolen credentials but it also penalizes submissions aren't made entirely "inside" -- their checking ignores RFC1918 addresses. To avoid Google's non-compliant behavior you must put the encoded information in a non-standard header, or toss it and rely on your logs. /mark ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] $GOOG
On 4/13/2022 10:27 PM, Al Iverson via mailop wrote: we've had somebody complain That's another discrepancy which I forgot to mention in my earlier response to Al's post - the type of "silent" blocks I was discussing - are often situations where, by their very nature, the user isn't even aware of the legit message being blocked since the sender didn't receive a non-delivery notification. So those "when someone complains" examples already have a built-in bias towards omitting the "silent block" situation I was describing, since users don't "complain" about problems they don't even know about. -- Rob McEwen, invaluement ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
