Do you follow all of the recommendations/requirements on
https://support.google.com/a/answer/81126 ?
Brandon
On Thu, Jun 5, 2025 at 10:04 AM Daniel R. Nash via mailop
wrote:
> Has anyone been able to resolve this gmail block? Our messages have been
> getting blocked progressively worse since Fe
s, but only when sent to a private domain mailboxes
> hosted by Google.
>
> Thanks for your feedback, everyone.
>
> ~Allen K
>
>
> On Thursday, May 29, 2025 at 05:29:32 PM EDT, Brandon Long via mailop <
> mailop@mailop.org> wrote:
>
>
> I would also point ou
I would also point out it wouldn't be the first time that a Google
error/warning/info message for spam/phishing things wasn't quite accurate.
My guess it is something that could be a spoofed email address, even if
it's not because of specific characters in it.
I'd guess that there is some small ed
Google has never supported SRS.
Gmail auto-forwarding does use VERP, though it is to make sure that bounces
go to Gmail in order to disable auto-forwarding if consistently bouncing,
and to hide the address you're forwarding to from the sender. It predates
SPF and was not designed to work around S
On Mon, Dec 9, 2024 at 2:25 AM Jaroslaw Rafa via mailop
wrote:
> Dnia 8.12.2024 o godz. 20:27:51 postfix--- via mailop pisze:
> > FACT: languages are living bodies of conventions common to two or
> > more individuals. Emojis are the glyphs of new languages in the
> > making. I get to learn eve
On Wed, Oct 16, 2024 at 2:22 PM Jaroslaw Rafa via mailop
wrote:
> Dnia 16.10.2024 o godz. 15:03:19 Michael Orlitzky via mailop pisze:
> > > 2. The benefit you cite is the usual one for the sender, but a) it
> > > ignores issues with receivers, and b) it ignores multi-hop scenarios.
> >
> > What i
On Wed, Oct 16, 2024 at 11:32 AM Slavko via mailop
wrote:
> Dňa 16. októbra 2024 18:13:45 UTC používateľ Brandon Long via mailop <
> mailop@mailop.org> napísal:
>
> >The general theory is that a replay involves mail for a DKIM domain
> >coming from different sources
On Wed, Oct 16, 2024 at 11:04 AM Dave Crocker wrote:
>
> On 10/16/2024 10:55 AM, Brandon Long via mailop wrote:
> > The most meaningful utility of SPF at the moment I think is to help
> > identify DKIM replay cases.
>
> I have tried to track the DKIM replay discus
On Wed, Oct 16, 2024 at 9:04 AM Dave Crocker via mailop
wrote:
> While SPF is entrenched, and challenges to its use typically gets a
> casual claim that it provides incremental benefit where DKIM fails, I
> believe there is no published data demonstrating that the incremental
> benefit is real an
On Wed, Sep 4, 2024 at 6:47 AM Bernardo Reino via mailop
wrote:
> On Sun, 1 Sep 2024, Viktor Dukhovni via mailop wrote:
>
> > The flaw for me is that TOTP involves using phone apps I don't know
> > the provenance of, that back up the data in a format I don't know
> > to my "Google Drive", which i
On Thu, Aug 29, 2024 at 9:18 PM Viktor Dukhovni via mailop <
mailop@mailop.org> wrote:
> On Wed, Aug 28, 2024 at 12:03:01PM -0700, Brandon Long wrote:
> > On top of that, if you make such an opt-out available, the people
> > using it are not going to be the people who have a level of know-how
> >
On Wed, Aug 28, 2024 at 11:06 PM Michael Rathbun via mailop <
mailop@mailop.org> wrote:
> On Wed, 28 Aug 2024 11:51:24 -0700, Brandon Long via mailop
> wrote:
>
> >Typically, the phone number use in cases like this is part of trying to
> >prevent bulk operations.
>
In some countries, the phone seller creates a gmail account and logs into
the phone, and the customer
never knows the account or password, and yeah, such accounts are definitely
disposable.
As pointed out, such an account is not actually required to use Android
devices, and there are about
a billi
I presume some wires are getting crossed.
It is true that you can have an Android phone without a Google Login.
You can use any phone as 2FA via SMS, including a logged out Android phone.
Or any device that supports a VOIP number.
Or any device that can run a TOTP authenticator app.
None of these
On Mon, Aug 26, 2024 at 10:35 PM Viktor Dukhovni via mailop <
mailop@mailop.org> wrote:
> On Tue, Aug 27, 2024 at 06:18:01AM +0200, Bryan Holloway via mailop wrote:
>
> > The password is correct, but it insists on verification from this user's
> no
> > longer existing cellphone. Yet the back-up ac
I'm not sure exactly what flow you're hitting, and it's been a while since
I've been in any loops about this stuff...
Typically, the phone number use in cases like this is part of trying to
prevent bulk operations.
If you think about a mass password exposure, there are cases where someone
is tryi
On Thu, Jul 11, 2024, 3:41 AM Jaroslaw Rafa via mailop
wrote:
> verification of each domain they want to
> register.
>
> The .eu.org free domains have been there since many years and from what I
> know, are rarely abused. But I guess some people immediately stop thinking
> when they hear about "f
Better case would be to automatically discover that a TLD is bad but also
provide for the possibility that a given domain in the TLD is fine using a
reputation based system.
Of course, then there's the "automatically know what the TLD is" problem
since it's not just the last segment.
And having e
On Tue, Jul 9, 2024 at 7:20 PM Scott Q. via mailop
wrote:
> What exactly is missing for broad acceptance ?
>
> https://openid.net/specs/openid-connect-discovery-1_0.html defines some
> pretty clear ways to autodiscover the endpoints.
>
> MS & Google and Keycloak both offer this URL:
>
>
> https:
At least in the past, some other types of auth failures at MS would result
in an SPF specific bounce message, including DKIM issues when they broke
signatures and tried to forward. I have no idea if this is still the case.
The other thing you ask, if there is no sender (ie a bounce from <>), you
There's also nothing to prevent you from DKIM signing your bounce messages.
"bounce" messages (nothing more than coming from a null sender) are often
used for spam. Gmail has always applied spam rules to them.
Brandon
On Mon, May 27, 2024 at 4:39 PM Kevin A. McGrail via mailop <
mailop@mailop.o
On Fri, May 17, 2024 at 4:18 PM John Levine wrote:
> It appears that Brandon Long via mailop said:
> >-=-=-=-=-=-
> >-=-=-=-=-=-
> >
> >RFC 3030 which provides for the BDAT command and BINARYMIME which treats
> >the message not as text at all
> >and so
RFC 3030 which provides for the BDAT command and BINARYMIME which treats
the message not as text at all
and so I wouldn't expect that that text limit would apply, though the RFC
doesn't discuss any limits.
In general, I don't see much utility in limiting the length of lines in the
body of messages
On Fri, May 17, 2024 at 1:07 PM John Levine via mailop
wrote:
> It appears that Taavi Eomäe via mailop said:
> >-=-=-=-=-=-
> >-=-=-=-=-=-
> >Hi!
> >
> >As part of coordinated disclosure, I am sharing it here as well. In
> >short, using the approach described below, attackers can replace the
> >
On Tue, May 14, 2024 at 12:09 AM Gellner, Oliver via mailop <
mailop@mailop.org> wrote:
> On 13.05.2024 at 17:12 von Aaron C. de Bruyn via mailop wrote:
>
> > While it was a groups permission issue, the GSuite logs for GMail do
> *not* show anything about a permission problem. See attached photo
The reason I added the address validation for mail from was because
otherwise we had no guarantee that we could send a bounce. Validation
stopped us from getting a bunch of invalid addresses we would then fail to
bounce back to.
The lack of handling for quoted addresses has been true since day on
On Mon, May 6, 2024 at 12:41 AM Alessandro Vesely via mailop <
mailop@mailop.org> wrote:
>
> The question is, since Gmail seems to require a DKIM signature just to
> make
> sure some domain is responsible for the message, doesn't an ARC seal cover
> the
> same requirement?
>
The most that ARC can
Most likely the reasoning behind something like this is dkim replay
attacks, where a message with a single recipient is re-sent to a large
number of recipients.
Of course mailing lists should be exempted, the challenge is if you reply
to both the list and the person directly, the reply to the pers
You may need to do some more work to be more specific in what causes the
crashes, so that you can have a more targeted approach.
Ie, is this a case of the client not handling an EAI message (raw utf-8 in
the from header), is it specific to specific characters, is it specific to
the being in the "c
On Mon, Jan 1, 2024 at 9:31 AM Simon Arlott via mailop
wrote:
> On 31/12/2023 16:02, John Levine via mailop wrote:
> > A message with a dozen recipients in the same SMTP session is a very
> > strong spam signal. So don't do that, do single deliveries like
> > everyone else does.
>
> Except that G
Hmm, doesn't this also depend on improper handling of pipelining?
You can't pipeline past DATA,
https://datatracker.ietf.org/doc/html/rfc2920#section-3.1
I guess if the sender is sending line by line, maybe the server would only
have up to the DATA in the tcp buffer and process the DATA before re
As stated previously, enforcement of the authentication required rules has
been ongoing for most of the year in limited ways (and in some respects,
many years).
The enforcement may apply to specific types of messages, sender
reputations, specific sender/recipient pairs, or a percentage of traffic.
I've raised a bug to take a look, this looks like a too broad dkim replay
rule.
Brandon
On Mon, Oct 2, 2023 at 1:35 AM Stephen Frost via mailop
wrote:
> Greetings,
>
> For about the past month we (PostgreSQL.Org mailing lists) have seen a
> large increase in the number of 421-4.7.28 "Our system
On Wed, Sep 27, 2023 at 6:14 AM John R Levine via mailop
wrote:
> >> I'm doing some work for arxiv.org, the preprint server at Cornell
> university.
> >>
> >> Many gmail users have reported that when they try to send mail to
> >> arxiv.org addresses to update their subscriptions, it fails saying
No, leading spaces in message headers are not allowed by the spec.
Nor are multiple From headers.
Multiple addresses in a single from header is technically allowed, but
Google has enforced against it since implementing DMARC nearly a decade ago.
A space in front of a header indicates a header co
Looking at the messages from that IP getting that rejection message, I'm
seeing a lot of DKIM body hash did not verify, I'd also verify that your
system isn't modifying the messages that it is forwarding.
Brandon
On Tue, Sep 12, 2023 at 8:20 PM Brandon Long wrote:
> That message did not have a
That message did not have a DKIM header ... or was so garbled that we
didn't extract it.
Due to DKIM replay, we may spam reject forwarded messages that DKIM verify
but not SPF, but those would not have that rejection message.
And yes, we are continuing to ramp no auth, no entry.
I'm sure I've ha
Note that SRS usually refers to a specific rewriting scheme, one that never
went beyond a draft
and wasn't all that useful directly. You can of course use it, but I don't
think the specific implementation
is that useful. There were people who felt that Gmail should support SRS
or that it already
I assumed most people had already tuned their systems to ignore +all or
overly broad IP ranges, spammers abused that like a decade ago.
I feel like we even discussed it here, including having to exempt Apple who
had their entire class A listed at one point (they no longer do).
Saying anyone can s
Thanks for the feedback, I've forwarded it to the maintainers.
Note that the mxtoolbox does not use the same libraries for evaluation as
Gmail itself, so the bugs in each are mostly independent. I wouldn't be
surprised at that, since validation is not usually
the same as evaluation, one might be
On Thu, Jun 1, 2023 at 11:20 AM Alessandro Vesely via mailop <
mailop@mailop.org> wrote:
> On Thu 01/Jun/2023 17:45:38 +0200 Robert L Mathews wrote:
> > So I guess it's time to add SRS rewriting for Gmail addresses...!
>
>
> The only points I see in SRS are mailbox full or oversize. You ought to
This is related to the note on https://support.google.com/mail/answer/81126
> Important: Starting November 2022, new senders who send email to Google
Gmail accounts must set up either SPF or DKIM
which is to say, what they're saying is use a domain you control and
authenticate it, and make an eff
On Fri, May 26, 2023 at 9:47 AM Scott Mutter via mailop
wrote:
> It just seems that if people would read the documentation for SPF and
> specify exactly what IP addresses are suppose to be sending email from your
> domain name (I mean... if you own that domain name, shouldn't you know what
> IP a
On Wed, May 17, 2023 at 3:18 PM Jaroslaw Rafa via mailop
wrote:
> Dnia 17.05.2023 o godz. 15:22:22 Bob Proulx via mailop pisze:
> > This behavior is such that one either loves it or hates it. Certainly
> > without understanding what's happening it makes using mailing lists
> > terribly confusing
On Fri, May 12, 2023 at 12:44 PM John Levine via mailop
wrote:
> It appears that Bill Cole via mailop <
> mailop-20160...@billmail.scconsult.com> said:
> >On 2023-05-12 at 09:40:14 UTC-0400 (Fri, 12 May 2023 13:40:14 +)
> >Paul Gregg via mailop
> >is rumored to have said:
> >
> >> I suspect
On Fri, May 12, 2023 at 8:54 AM Bill Cole via mailop
wrote:
> On 2023-05-12 at 09:40:14 UTC-0400 (Fri, 12 May 2023 13:40:14 +)
> Paul Gregg via mailop
> is rumored to have said:
>
> > I suspect with verp/bounce addressing widely in use now, 64 octets
> > just
> > isn't enough these days.
>
>
Confirmed this looks like a bug on our end, I've filed a bug to have the
team look at it.
Brandon
On Thu, May 11, 2023 at 9:34 AM Jarland Donnell via mailop <
mailop@mailop.org> wrote:
> Curious if anyone else is seeing an increase in errors like this from
> Google:
>
> 550-5.7.25 [136.175.108.2
This smtp response doesn't match this email message. In any case, both of
these messages did pass authentication, but we chose the wrong error
message to send in response to this one (the other was accepted).
I'll file a bug.
Brandon
On Fri, Apr 21, 2023 at 1:02 AM Alessandro Vesely via mailop <
Google Cloud, which I assume is what googleusercontent.com is from this, is
only unblocked for smtp for supposedly good customers... though I think
they are allowed to connect to the Workspace relays (but then I wouldn't
expect them to come from googleusercontent.com but from the regular
Workspace
On Fri, Mar 3, 2023 at 10:07 AM Mark Fletcher via mailop
wrote:
> On Fri, Mar 3, 2023 at 9:21 AM Jesse Hathaway via mailop <
> mailop@mailop.org> wrote:
>
>>
>> 1. Rewrite the RFC5322.From address to be an address from the mailing
>> list domain, place the original RFC5322.From address in the Rep
It's the from address they're talking about, it means they can't use an EAI
from address for these cases, they would need to either not send or have a
fallback non-EAI address for the messages.
Brandon
On Fri, Mar 3, 2023 at 12:37 PM Ángel via mailop wrote:
> On 2023-03-03 at 09:37 -0700, Alex
https://www.rfc-editor.org/rfc/rfc6532#section-3
> Also note that messages in this format require the use of the
> SMTPUTF8 extension [RFC6531] to be transferred via SMTP.
On Thu, Mar 2, 2023 at 3:38 PM Alex Burch wrote:
> I am using unicode in the From: not the MAIL FROM. Do you have to specify
I don't think anyone sics lawyers on anything that small.
The sure magnitude of the abusers who use various copyrighted names and the
effort in international jurisdiction to hunt them down, good luck.
I do wish we did more at least with the bigger ones like Microsoft did
several years ago, but I
Did you specify SMTPUTF8 on the MAIL FROM command? Is swaks that smart?
doesn't look like it.
https://github.com/jetmore/swaks/blob/6bc61708489dc9789246e8fe58d32a0ff4fec8f4/swaks#L1055
Our validation cares, though it uses the same error message in either case,
so I guess it should say RFC6532 if
That error message is not overly accurate in this case, unfortunately. The
fact that it was a temp fail means its throttling, which can definitely
happen when there is infrequent sending, so the behavior is "unusual"... it
can be very common for a low to high sending change to be due to domain
rea
Ugh, looks like when I added our NULL MX records in 2016, it was only for
our other domains that don't receive email, not for the odd gmail typos
that have special web handling redirections.
I'll file a ticket.
Brandon
On Thu, Feb 16, 2023 at 11:06 AM Matthew Pounsett via mailop <
mailop@mailop.
On Wed, Jan 18, 2023 at 6:35 PM Michael Peddemors via mailop <
mailop@mailop.org> wrote:
> Thanks Brandon,
>
> for the quick response, and of course can confirm in those cases there
> is no To or Cc recipients in that email, however we have a hard time
> telling if this is a broken script kiddie j
Note that Gmail implements
https://www.rfc-editor.org/rfc/rfc5322#section-3.6.3 option 2, notably:
In the second
case, recipients specified in the "To:" and "Cc:" lines each are sent
a copy of the message with the "Bcc:" line removed as above, but the
recipients on the "Bcc:" line get
It is unlikely anyone with a large user base of enterprise customers can do
something as simple as "don't relay messages with bad message-ids".
I presume you only care because this was spam, but evaluating how much
non-spam this issue also applies to is more complicated.
Internal relays are a hor
Huh, wonder if that got caught in an existing spam rule, an ML inferred
rule, or just that quickly pissed off users to mark it as spam?
Brandon
On Mon, Nov 28, 2022 at 8:27 AM Allen Kevorkov via mailop
wrote:
> Happy Cyber Monday, ya'll.
>
> Not sure who needs to hear this, but sender with high
__
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
> I appreciate the feedback from you both! I'll see if this is something we
> can confirm/exclude.
>
> J
>
> On Tue, Nov 8, 2022 at 3:15 PM Brandon Long via ma
On Tue, Nov 8, 2022 at 3:45 PM MRob via mailop wrote:
> On 2022-11-08 22:51, Brandon Long via mailop wrote:
> > Validating From headers is the whole thing behind DMARC. Yes, an MSP
> > should validate the From header for mail it originates, but there are
> > often
>
Another one I've seen is an extra newline which ends the headers, ie:
Subject: foo
To: b...@example.net
From: campa...@example.org
I don't recall how annoying our parser is, whether something like this
would also cause early end of headers:
Subject: foo
To: bar@
example.net
From: campa...@examp
Validating From headers is the whole thing behind DMARC. Yes, an MSP
should validate the From header for mail it originates, but there are often
cases such as various kinds of relaying, where doing so is not possible.
One can use DMARC or other heuristics to try and figure that out when
forwarding
Envelope sender, and then the email
>> address with the +caf in it, and Equals or contains match type
>> Reject Message
>>
>> Brandon
>>
>>
>>
>> On Mon, Oct 24, 2022 at 11:01 AM Tara Natanson
>> wrote:
>>
>>> Brandon,
>>&g
Brandon,
>
> The forward is set up to send out our postmaster@ address, So I can't
> let it bounce. :(
>
> Tara
>
>
> On Mon, Oct 24, 2022 at 1:49 PM Brandon Long via mailop
> wrote:
>
>>
>>
>> On Mon, Oct 24, 2022 at 9:09 AM Bill Cole via mailop
On Mon, Oct 24, 2022 at 9:09 AM Bill Cole via mailop
wrote:
> On 2022-10-24 at 09:30:29 UTC-0400 (Mon, 24 Oct 2022 09:30:29 -0400)
> Tara Natanson via mailop
> is rumored to have said:
>
> > Yes I know the address @gmail the messages are being sent to. I do not
> > control that gmail inbox tho
On Mon, Oct 17, 2022 at 10:43 PM Grant Taylor via mailop
wrote:
> On 10/17/22 10:17 PM, Brandon Long via mailop wrote:
> > Right, but you can't stick a non-compliant message into a DSN
> > directly and have that be a compliant message... so you either make
> > the non-c
On Mon, Oct 17, 2022 at 9:07 PM Grant Taylor via mailop
wrote:
> On 10/17/22 9:11 PM, Brandon Long via mailop wrote:
> > Certainly, but do you consider some edge cases like composing bounces
> > or relaying messages as generating messages?
>
> Yes, generating a DSN is ge
On Mon, Oct 17, 2022 at 7:49 PM Grant Taylor via mailop
wrote:
> On 10/17/22 8:35 PM, Brandon Long via mailop wrote:
> > The line length limit was clearly designed for a different time in
> > terms of memory usage, and I think a lot of mail software has much
> > larger wor
Rewriting messages which are poorly formatted can have downstream effects
on DKIM signatures,
so you have to weigh the consequences for your environment.
The line length limit was clearly designed for a different time in terms of
memory usage, and
I think a lot of mail software has much larger wor
What you should sign up for is postmaster.google.com, which would show
when the issue occurred, and the IPs involved.
Given that your SPF record appears to have been updated since then, I
imagine you or someone else at your org may suspect what caused the issue.
Brandon
On Sun, Oct 2, 2022 at 3:
On Thu, Sep 29, 2022 at 12:44 PM Jaroslaw Rafa via mailop
wrote:
> Dnia 29.09.2022 o godz. 10:33:38 Brandon Long via mailop pisze:
> > The PSL only tells you what's the TLD and what's not, that doesn't mean
> you
> > can't consider
> > a TLD a bad sp
ilop
wrote:
> Dnia 29.09.2022 o godz. 10:02:53 Brandon Long via mailop pisze:
> >
> > Another is the same old PSL issue, rDNS is rarely going to match the
> exact
> > domain, and sub-domain
> > matching can go awry. Obviously things like DMARC also rely on PSL,
On Thu, Sep 29, 2022 at 10:27 AM Jarland Donnell via mailop <
mailop@mailop.org> wrote:
> That little ~ is the part that gets me and I think opens it up to any IP
> more than the parts before it. I always interpret ~ like a shoulder
> shrug, so as to read this:
>
> v=spf1 a mx ~all
>
> Like this i
On Thu, Sep 29, 2022 at 7:32 AM Renaud Allard via mailop
wrote:
>
>
> On 9/29/22 15:27, Stefan Neufeind via mailop wrote:
> > Hi,
> >
> > I recently came across an email being rejected by gmail.com with:
> >
> > This message does not pass authentication checks (SPF and DKIM both do
> > not pass).
On Wed, Sep 28, 2022 at 11:39 AM Dave Crocker wrote:
>
> On 9/19/2022 11:59 AM, Brandon Long wrote:
>
>
>
> On Sat, Sep 17, 2022 at 11:10 AM Dave Crocker via mailop <
> mailop@mailop.org> wrote:
>
>>
>> On 9/16/2022 7:35 PM, Brandon Long via mailop wr
On Wed, Sep 21, 2022 at 2:47 AM Alessandro Vesely via mailop <
mailop@mailop.org> wrote:
> On Tue 20/Sep/2022 16:59:36 +0200 John R Levine via mailop wrote:
> >>> As I think I've mentioned many times before, the problem that ARC
> solves is
> >>> that legit lists leak spam because they often do no
On Tue, Sep 20, 2022 at 1:42 PM Jay Hennigan via mailop
wrote:
> On 9/20/22 13:19, Brandon Long via mailop wrote:
>
> > otoh, if that's not what they mean by "reading email", then I guess the
> > rest of the smarts that read email are still there, as this articl
While I doubt our say so will have much affect, Gmail hasn't scanned email
for ads since 2017, and that was consumer, GSuite/Workspace/GAFYD/etc I
think didn't have it ever, though there were versions of that (EDU and for
ISPs) that may have (looks like EDU was disabled in 2014)
https://blog.googl
On Mon, Sep 19, 2022 at 3:16 PM Slavko via mailop wrote:
> Dňa 19. septembra 2022 21:44:08 UTC používateľ Brandon Long via mailop <
> mailop@mailop.org> napísal:
>
> >Using machine learning for personal mail or very few users, not sure if
> >that's likely to
>
On Mon, Sep 19, 2022 at 2:39 PM Slavko via mailop wrote:
> Dňa 19. septembra 2022 20:45:27 UTC používateľ Brandon Long <
> bl...@google.com> napísal:
>
> >The simple answer is you add that signal to the list of other signals in
> >your machine learning
> >model and let the model training figure o
On Mon, Sep 19, 2022 at 12:43 PM Slavko via mailop
wrote:
> Dňa 19. septembra 2022 19:05:38 UTC používateľ Brandon Long <
> bl...@google.com> napísal:
>
>
> >I think many people here will point out that user interface changes will
> >have little effect on how customers interact with spam/phishing
On Mon, Sep 19, 2022 at 11:44 AM Slavko via mailop
wrote:
> Dňa 19. septembra 2022 15:38:35 UTC používateľ Dave Crocker via mailop <
> mailop@mailop.org> napísal:
> >
> >On 9/17/2022 8:12 AM, Jim Popovitch via mailop wrote:
> >> and DMARC was to fix what DKIM broke,
> >> and DKIM was to fix what
On Sat, Sep 17, 2022 at 11:10 AM Dave Crocker via mailop
wrote:
>
> On 9/16/2022 7:35 PM, Brandon Long via mailop wrote:
>
> So, while AOL & Yahoo were the vanguard for mass consumer providers, the
> problems were already being experienced by many corporate domains before
&g
On Fri, Sep 16, 2022 at 3:36 PM John Levine via mailop
wrote:
> It appears that Gellner, Oliver via mailop said:
> >
> >> Am 16.09.2022 um 19:22 schrieb Grant Taylor via mailop <
> mailop@mailop.org>:
> >> The mailing list is the terminus of the message that I'm typing. The
> mailing list is al
On Wed, Sep 14, 2022 at 3:39 AM Thomas Walter via mailop
wrote:
>
>
> On 14.09.22 11:24, Renaud Allard via mailop wrote:
> > On 9/14/22 10:57, Alessandro Vesely via mailop wrote:
> >> * Stop blackholing.
> >
> > That one is the absolute worst of the worst of the worst. Blackholing is
> > som
On Mon, Sep 12, 2022 at 4:16 PM Paul Kincaid-Smith
wrote:
>
> We have a reasonably large sample of messages sent from Gmail, Yahoo and
> Outlook and can assess how much was "spam foldered" by each of those
> services. We are in the same ballpark as John Levine, who estimated that
> "about 30% of
On Mon, Sep 12, 2022 at 3:11 PM Jay Hennigan via mailop
wrote:
> On 9/12/22 14:39, Brandon Long via mailop wrote:
>
> > I think if that were true, the amount of spam coming out of them would
> > be much
> > higher. Unfortunately, even a 1% false-negative rate would sti
On Mon, Sep 12, 2022 at 2:06 PM Jay Hennigan via mailop
wrote:
> On 9/12/22 10:23, Grant Taylor via mailop wrote:
> > On 9/12/22 5:13 AM, Thomas Walter via mailop wrote:
> >> What bothers me most is that the oligopoly makes it impossible to
> >> deliver emails to protect their users from spam, ye
On Mon, Sep 12, 2022 at 10:26 AM Grant Taylor via mailop
wrote:
> On 9/12/22 5:13 AM, Thomas Walter via mailop wrote:
> > What bothers me most is that the oligopoly makes it impossible to
> > deliver emails to protect their users from spam, yet it is the biggest
> > source of it…
>
> Does anyone
I mean, SPF can't pass if there is no SPF record, so the error message is
correct... but a more specific one for the reason SPF failed could be
useful, I guess.
And it's not 100% required yet, but it's been trending that way for a while.
Brandon
On Sat, Aug 27, 2022 at 10:05 PM Jarland Donnell v
On Sun, Aug 28, 2022 at 8:47 AM Alessandro Vesely via mailop <
mailop@mailop.org> wrote:
> On Sat 27/Aug/2022 00:54:47 +0200 Brandon Long wrote:
> >> There are certainly plenty of people who didn't read the spec and
> >> wrongly assume that a failed signature means something is wrong.
> >
On Fri, Aug 26, 2022 at 10:19 AM John Levine via mailop
wrote:
> It appears that Laura Atkins via mailop said:
> >-=-=-=-=-=-
> >-=-=-=-=-=-
> >
> >To answer your first question: a lot of mail is double signed. Signing
> with 2 identical d= but different s= is unusual, but I
> >don’t think it’s
RFCs are mostly an attempt at consensus, not suicide pacts.
Limits designed a decade ago before most organizations started using them
(and before the continuous growth in outsourcing) are not
necessarily the best choices.
Anyways, despite implementing our code while the spf rfc was still in
draft
On Fri, Aug 19, 2022 at 3:58 PM Jaroslaw Rafa via mailop
wrote:
> Dnia 19.08.2022 o godz. 10:31:32 Brandon Long via mailop pisze:
> > I won't say that OAUTH is the perfect solution to all of these issues,
> but
> > it is definitely an improvement for them.
> > Cou
On Fri, Aug 19, 2022 at 3:06 AM Stuart Henderson via mailop <
mailop@mailop.org> wrote:
> On 2022/08/19 09:08, Gellner, Oliver via mailop wrote:
> > Hello,
> > IMAP, SMTP etc are still being supported with Office365. What gets
> > disabled is Basic Auth for some services. Microsoft announced the
>
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 scorin
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
"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, n
1 - 100 of 605 matches
Mail list logo
