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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 <
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
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
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
___
> 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 mailop
> wrote:
&g
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:
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
th 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,
>>>
>>> The forward is set up to send out our p
don,
>
> 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
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-compli
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
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
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 spam source. There ar
nia 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, so
> it
> >
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
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
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 mailo
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
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 article
>
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)
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
> >b
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
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
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
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
> >
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,
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
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
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.
> > Could TL
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
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
"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,
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
>
https://developers.google.com/gmail/ampemail is the Google developer
information about dynamic email, that link was about controlling the
content with Google Workspace.
The standardization is via AMP, docs at https://amp.dev/about/email/ and a
pretty short list of other providers who support it.
You could also allow the TLS connection and then fail some percentage of
mail attempts after that with a 5xx message to tell your admin to upgrade
their encryption strength.
Failing the TLS negotiation typically has really terrible debuggability as
the other thread about SHA1 on Gmail speaks to.
On Wed, Aug 3, 2022 at 10:07 AM Grant Taylor via mailop
wrote:
> On 8/3/22 9:46 AM, Jarland Donnell via mailop wrote:
> > It's a pretty big and well respected security practice to consider plain
> > text to be more secure than insecure SSL for one reason: A plain text
> > connection isn't logged
I would caution against assuming that legal analysis is required to match
technical analysis.
At the least, any legal proceedings would involve a lot of argument over
exactly what the words
in the statute mean, what the intent of the legislature was, and whether
reasonable attempts were made
to
Any paid workspace account should have access to customer support, either
directly or through their reseller.
That said, I agree, there probably isn't that much customer support can do
looking at the outbound
side... and investigating the inbound side of another customer is not
likely ... in
Are they using Windows Mail to send mail through your service via message
submission?
Adding a message-id header is a SHOULD in that case:
https://datatracker.ietf.org/doc/html/rfc6409#page-14
If you're just forwarding, then yes, it's unfortunate.
Brandon
On Mon, Jul 18, 2022 at 4:24 PM Robert
On Sun, Jul 10, 2022 at 10:28 AM Andrew C Aitchison via mailop <
mailop@mailop.org> wrote:
>
> On Sun, 10 Jul 2022, Anne Mitchell via mailop wrote:
> >> On Jul 9, 2022, at 8:15 PM, Brett Schenker via mailop <
> mailop@mailop.org> wrote:
> >>
> >> Just put it all in quarantine. It only requires
answering with no insider knowledge, I just read the request, and the
reason for the request is in there, and matches what I expect... there are
strict rules
in the US about political donations, so making sure that this is not
considered a political donation is in the interests of Google on pain
As far as the rfc ignorant rejections, the rules about some duplicate
headers have been ramping for a couple months, but only recently was the
error message updated to point out what the issue is, before it was a more
generic might be spam message.
This is in addition to the rules we've had for
Unfortunately, false negatives still apply to other features of the
forwarding host, not rewriting only
helps them from applying to your SPF domain.
Forwarding more than say 10 or 20% spam will start to cause problems either
way.
I was surprised they are listening to SPF -all, I would have
On Thu, Jun 16, 2022 at 7:26 PM Dan Mahoney wrote:
> On Jun 16, 2022, at 3:55 PM, Brandon Long via mailop
> wrote:
>
> You should get a welcome message when a user direct subscribes you to a
> group that should have an unsubscribe link in it. The welcome message par
Yeah, double dashes is not allowed in rfc821 mailboxes unless quoted, I
wondered about that myself. I guess the current groups impl isn't
enforcing those rules correctly, or maybe expects the mail server to quote
them.
In reality, most mail servers don't interpret addresses that strictly, and
I
SRS isn't anything, it was a draft that went nowhere and has no mechanism
for authentication. It's basically the same thing as any other ezmlm-style
bounce rewriting, with maybe some utility for the relaying server to
validate a bounce... but not really.
SPF is only useful for the sender, and
You should get a welcome message when a user direct subscribes you to a
group that should have an unsubscribe link in it. The welcome message part
of the flow that the group manager can set should be added to that message.
There are limits on how many people a group manager can add in this way,
On Thu, Jun 9, 2022 at 10:07 AM Brandon Long wrote:
>
>
> On Thu, Jun 9, 2022 at 7:47 AM Otto J. Makela wrote:
>
>> On 08/06/2022 21.25, Brandon Long via mailop wrote:
>>
>> > so the false positive rate for the new rule is better. It doesn't
>> &
On Thu, Jun 9, 2022 at 7:47 AM Otto J. Makela wrote:
> On 08/06/2022 21.25, Brandon Long via mailop wrote:
>
> > so the false positive rate for the new rule is better. It doesn't
> > even need to be a new rule, maybe your reputation just decreased
> > slightly and it no
On Thu, Jun 9, 2022 at 8:55 AM Michael Peddemors via mailop <
mailop@mailop.org> wrote:
> Yeah, when legit operators have to obfuscate their URL's, you know
> something isn't working right..
>
> We saw something similar, we send monthly payment receipts with a URL
> for the customer to update
While I have no idea what if anything changed that people are seeing here,
generally speaking the error messages
available at smtp for spam rejections are few (generally format, content,
auth, source), and there is a separate
mapping which links the spam rules that fired to the list of messages or
On Fri, May 6, 2022 at 2:31 PM Andrew C Aitchison via mailop <
mailop@mailop.org> wrote:
>
> > On Fri, May 6, 2022 at 8:52 PM John Levine via mailop >
> > wrote:
> >> Until then, I tell people who ask me to forward mail to Gmail that if
> >> they actually want to get the mail, I'll put it in a
On Fri, May 6, 2022 at 12:48 AM Dan Mahoney wrote:
> Two inline thoughts.
>
> On Apr 30, 2022, at 4:48 PM, Ángel via mailop wrote:
>
> On 2022-04-29 at 10:28 -0700, Brandon Long wrote:
>
> There have been other reports on this list of Gmail requiring
> authenticated email.
>
> We don't require
On Fri, May 6, 2022 at 10:58 AM Andrew C Aitchison via mailop <
mailop@mailop.org> wrote:
>
> On Fri, 6 May 2022, Grant Taylor via mailop wrote:
> > On 5/6/22 9:14 AM, Luis E. Muñoz via mailop wrote:
> >> I think the response to those issues are in part the cause for the loop
> you
> >> cleverly
1 - 100 of 539 matches
Mail list logo
