On Tue, 2023-02-28 at 12:31 +0100, Jaroslaw Rafa via mailop wrote:
>
> I do greylisting, and that's how I found out about the immediate
> retries. I run postgrey with default setting which is 5 minutes, and
> I often see in logs multiple retries within those 5 minutes, with
> first ones being
On Mon, 2023-02-27 at 21:38 -0700, Luke wrote:
>
> First, we send a lot of email; 9 billion messages on black friday
> alone. Each message generates an average of 8 events (deferrals,
> opens, clicks, spam reports, unsubscribes etc). Storage cost is a
> small part of the reason for minimizing MTA
On 2023-02-28, Jaroslaw Rafa via mailop wrote:
> Dnia 28.02.2023 o godz. 11:10:05 Julian Bradfield via mailop pisze:
>> Maybe worth pointing that people do greylisting, and with
>> greylisting it's helpful to retry quite soon. Immediately isn't
>> useful, but within five minutes is. (I
Dnia 28.02.2023 o godz. 11:10:05 Julian Bradfield via mailop pisze:
> On 2023-02-28, Jaroslaw Rafa via mailop wrote:
> > Another nonsense thing for me is that some senders - again, mostly the big
> > ones - retry almost *immediately* (often from a different IP address) if
> > they encounter a
On 2023-02-28, Jaroslaw Rafa via mailop wrote:
> Another nonsense thing for me is that some senders - again, mostly the big
> ones - retry almost *immediately* (often from a different IP address) if
> they encounter a 4xx, and after a few such unsuccessful retries (within only
> a few minutes)
Dnia 27.02.2023 o godz. 21:38:01 Luke via mailop pisze:
> Second factor (and the main factor) is our customers. We send 32 deferral
> events over the course of 72 hours to our customers' data warehouses for
> each message that reaches max queue time. That's 32 events they are
> consuming and
Those possible (and likely) explanations for a few of the rejections are
actually really insightful. It sounds like we agree that there are cases
where 4xx should not be retried. That's progress! The question around the
downside of queuing them up for a while is essentially 2-part.
First, we send
On Mon, 2023-02-27 at 18:53 -0700, Luke via mailop wrote:
> For better or worse, *not *retrying *some *4xx is even easier to
> justify.
> Here are a few massive examples.
>
> 421 4.7.1 Message permanently deferred:
>
> 452 Sender Rejected:
Keeping in mind that the RFC says not to use the text
For better or worse, *not *retrying *some *4xx is even easier to justify.
Here are a few massive examples.
421 4.7.1 Message permanently deferred: less than 1% delivered rate after
32 retries. This is across 100s of millions of messages, thousands of
unique senders, and thousands of IPs, looking
On Mon, 2023-02-27 at 15:45 -0700, Luke via mailop wrote:
>
> With that said, given the responses in this thread, we will be taking
> a close look at the few rules we have in place where we retry 5xx and
> see if A.) the rules are still being hit at all, and B.) are these
> retries still
I can't go into the specifics in great detail, but I want to make it clear
that these are rare edge cases. We aren't out there retrying 5xx every
chance we get because we don't care about being a good citizen. These are
small scale, often short-lived exceptions where retrying a very specific
5xx
It appears that Kelly Molloy via mailop said:
>On Fri, Feb 24, 2023 at 7:14 PM Matt Palmer via mailop
> wrote:
>> That's something to talk to your ESP about. They're in charge of retrying.
>
>Christine *is* the ESP.
She's at Shopify, but Sendgrid is the ESP.
Perhaps she can confirm with
On Mon, 2023-02-27 at 04:55 +, Denny Watson via mailop wrote:
>
> All I have said (which you had conveniently redacted) is that RFC5321
> leaves the door open to process bounces differently should the
> sending MTA be able to determine the reason for non-delivery.[1]
>
> ...
>
> [1] See my
On Fri, Feb 24, 2023 at 7:14 PM Matt Palmer via mailop
wrote:
> That's something to talk to your ESP about. They're in charge of retrying.
Christine *is* the ESP.
Kids these days.
___
mailop mailing list
mailop@mailop.org
On 2/26/2023, Michael Orlitzky via mailop wrote:
On Sun, 2023-02-26 at 19:43 +, Denny Watson via mailop wrote:
This appears to be a specially built MTA, and with the (probable)
consent of its users, has policy in place to not resend after 4xx under
specific conditions. I.e. the sending MTA
Luke, you might want to share SendGrid's logic on that. to the list. if
you keep sending to 5xx too many times, that will be 'bad' for your
reputation.
When/where do you retry? How often, for how long.. under what circumstances?
On 2023-02-25 19:15, Luke via mailop wrote:
I can assure you
On Sun, 2023-02-26 at 19:43 +, Denny Watson via mailop wrote:
> This appears to be a specially built MTA, and with the (probable)
> consent of its users, has policy in place to not resend after 4xx under
> specific conditions. I.e. the sending MTA is interpreting specific 4xx
> responses
> This appears to be a specially built MTA, and with the (probable)
> consent of its users, has policy in place to not resend after 4xx under
> specific conditions. I.e. the sending MTA is interpreting specific 4xx
> responses (and more likely the text) to mean a permanent failure.
>
> I do not
On 2/24/2023, Christine Borgia via mailop wrote:
It is transient, but they are blocks and are not retried. Weird, right?
I have an opinion on this;
This appears to be a specially built MTA, and with the (probable)
consent of its users, has policy in place to not resend after 4xx under
Dnia 25.02.2023 o godz. 19:15:14 Luke via mailop pisze:
> How is it 2023 and people still think
> 4xx means retry and 5xx means don't retry?
Because it does. As simple as that.
--
Regards,
Jaroslaw Rafa
r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know:
On 2023-02-25 19:15:14, Luke via mailop wrote:
> I can assure you sendgrid retries 4xx. We also don't retry 4xx. We also
> retry 5xx. We also don't retry 5xx. How is it 2023 and people still think
> 4xx means retry and 5xx means don't retry?
>
It's literally unexplainable if you've never read
On Sun, 26 Feb 2023 10:34:11 +, Laura Atkins via mailop
wrote:
>If people intend to be interoperable, there is NO variation in what a 4xx and
>a 5xx mean.
>
>4xx means: this message can be queued and retried at a future date.
>
>5xx means: this message cannot be retried without human
Ahoj,
Dňa Sun, 26 Feb 2023 10:34:11 + Laura Atkins via mailop
napísal:
> If people intend to be interoperable, there is NO variation in what a
> 4xx and a 5xx mean.
>
> 4xx means: this message can be queued and retried at a future date.
>
> 5xx means: this message cannot be retried
If people intend to be interoperable, there is NO variation in what a 4xx and a
5xx mean.
4xx means: this message can be queued and retried at a future date.
5xx means: this message cannot be retried without human intervention.
Those interactions are defined in RFC 821 and it’s successors. [1]
There's a lot of variation in what 4xx and 5xx mean in practice. This means
there's room for some senders to spend time investigating and understanding
what each receiving domain's 4xx and 5xx (and subcategories thereof)
actually mean for address delivery over time, and for designing rules and
Luke via mailop skrev den 2023-02-26 04:15:
I can assure you sendgrid retries 4xx. We also don't retry 4xx. We
also retry 5xx. We also don't retry 5xx. How is it 2023 and people
still think 4xx means retry and 5xx means don't retry?
what books do you read ?
maybe rfc 7505 is soon or later for
I can assure you sendgrid retries 4xx. We also don't retry 4xx. We also
retry 5xx. We also don't retry 5xx. How is it 2023 and people still think
4xx means retry and 5xx means don't retry?
Luke
On Sat, Feb 25, 2023, 9:21 AM Michael Orlitzky via mailop
wrote:
> On Fri, 2023-02-24 at 15:57
Dnia 24.02.2023 o godz. 09:51:02 Mark Milhollan via mailop pisze:
> Did you read the link? Does your ESP have a postmaster account? If
> they don't send enough messages ("a large volume") to Gmail they
> won't provide any information about reputation, except that that
> itself indicates that you
On Fri, 2023-02-24 at 15:57 -0500, Christine Borgia via mailop wrote:
> It is transient, but they are blocks and are not retried. Weird, right?
>
SendGrid doesn't retry on 4xx and haven't for many years.
___
mailop mailing list
mailop@mailop.org
On 25/02/2023 12:32, Benny Pedersen via mailop wrote:
Simon Greenwood via mailop skrev den 2023-02-24 22:09:
This (which I didn't know) adds a whole different aspect to the issue
- much has been said about how email is now centralised and is almost
impractical to run as a small operator
Matt Palmer via mailop skrev den 2023-02-25 01:01:
[Fixed TOFU]
On Fri, Feb 24, 2023 at 03:57:00PM -0500, Christine Borgia via mailop
wrote:
On Fri, Feb 24, 2023 at 1:09 PM Benny Pedersen via mailop
wrote:
> Christine Borgia via mailop skrev den 2023-02-24 17:17:
>
> >>> 421 4.7.0
Simon Greenwood via mailop skrev den 2023-02-24 22:09:
This (which I didn't know) adds a whole different aspect to the issue
- much has been said about how email is now centralised and is almost
impractical to run as a small operator level, but if a company like
Shopify and indeed Sendgrid
Christine Borgia via mailop skrev den 2023-02-24 21:57:
It is transient, but they are blocks and are not retried. Weird,
right?
proff from logs is ?
others say this ip is not google but sendgrid
simple "mailq" will show it
___
mailop mailing list
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
In defense of Google on that, Christine works for Shopify. Shopify is a
huge spam outlet. If you want to flood someone's inbox with junk, find
thousands of shopify sites and sign them up for their newsletters. Zero
double opt in procedures, and if you happen to get a response to abuse
On 2023-02-24 at 16:09:26 UTC-0500 (Fri, 24 Feb 2023 21:09:26 +)
Simon Greenwood via mailop
is rumored to have said:
[...]
This (which I didn't know) adds a whole different aspect to the issue
- much has been said about how email is now centralised and is almost
impractical to run as a
[Fixed TOFU]
On Fri, Feb 24, 2023 at 03:57:00PM -0500, Christine Borgia via mailop wrote:
> On Fri, Feb 24, 2023 at 1:09 PM Benny Pedersen via mailop
> wrote:
>
> > Christine Borgia via mailop skrev den 2023-02-24 17:17:
> >
> > >>> 421 4.7.0 [149.72.90.158 15] Our system has detected that this
On 24/02/2023 19:19, Rob McEwen via mailop wrote:
Did you read the link? Does your ESP have a postmaster account? If
they don't send enough messages ("a large volume") to Gmail they
won't provide any information about reputation, except that that
itself indicates that you haven't (and
It is transient, but they are blocks and are not retried. Weird, right?
On Fri, Feb 24, 2023 at 1:09 PM Benny Pedersen via mailop
wrote:
> Christine Borgia via mailop skrev den 2023-02-24 17:17:
>
> >>> 421 4.7.0 [149.72.90.158 15] Our system has detected that this
>
> > If someone could reach
On 2023-02-24 12:38, Andrew C Aitchison via mailop wrote:
On Fri, 24 Feb 2023, Alessandro Vesely via mailop wrote:
On Fri 24/Feb/2023 18:41:34 +0100 Christine Borgia via mailop wrote:
I also should have mentioned we use shared IPs so there is no issue
with volume from our servers, however
On Fri, 24 Feb 2023, Rob McEwen wrote:
Quite frankly, I'm constantly amazed at how often I see assumptions from so
many - that assume Google is always right and the other entity is wrong - even
when all the facts point to the opposite.
I never said Google was "right", but if you want to
On 2/24/23 10:40, Simon Greenwood via mailop wrote:
61 entries in SORBS, last January 23rd .
This should be noted to your ESP
$ whois 149.72.90.158
NetRange: 149.72.0.0 - 149.72.255.255
CIDR: 149.72.0.0/16
NetName:SENDGRID-149-72-0-0-16
Good luck with that.
--
>which pass FCrDNS and where they dynamic PTR records
oops - typo - I meant to say, "and where they're NOT dynamic"
Rob McEwen, invaluement
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Did you read the link? Does your ESP have a postmaster account? If they don't send
enough messages ("a large volume") to Gmail they won't provide any information
about reputation, except that that itself indicates that you haven't (and can't) collect
enough reputation to be other than low
61 entries in SORBS, last January 23rd .
This should be noted to your ESP, but you may be in a bit of cleft stick
in this situation - changing IPs or upgrading to a exclusive IP would
still require reputation to be maintained, but shared IPs in a lot of
ESPs now suffer from this kind of
On Fri, 24 Feb 2023, Alessandro Vesely via mailop wrote:
On Fri 24/Feb/2023 18:41:34 +0100 Christine Borgia via mailop wrote:
I also should have mentioned we use shared IPs so there is no issue with
volume from our servers, however volume from the domain is definitely
spikey. They only send
On Fri, 24 Feb 2023, Christine Borgia wrote:
I have a customer whose email campaign was heavily
blocked yesterday by Gmail with the error:
421 4.7.0 [149.72.90.158 15] Our system has detected that this message is
suspicious due to the very low reputation of the sending domain. To best
protect
Christine Borgia via mailop skrev den 2023-02-24 17:17:
421 4.7.0 [149.72.90.158 15] Our system has detected that this
If someone could reach out to me, I'd greatly appreciate it. I'm not
sure what to advise this customer except to say that email may not
work for their business model.
note
On Fri 24/Feb/2023 18:41:34 +0100 Christine Borgia via mailop wrote:
I also should have mentioned we use shared IPs so there is no issue with volume
from our servers, however volume from the domain is definitely spikey. They
only send every 2-3 months when they promote a new event.
I think
Thanks Simon and Ken! I am not aware of them having any abuse outside of
our platform. I have no evidence of it.
I also should have mentioned we use shared IPs so there is no issue with
volume from our servers, however volume from the domain is definitely
spikey. They only send every 2-3 months
Hello -
Check the domain with MXToolbox if you haven't all ready - it's not
impossible that the domain or servers are on a blacklist.
Also check that SPF and DKIM/DMARC records are good and set up for your
sending service and that reverse lookups are correct.
Reputation in this case
Hi Christine,
I wonder if the domain has been abused elsewhere?
Regards,
Ken
On Fri, Feb 24, 2023 at 8:21 AM Christine Borgia via mailop <
mailop@mailop.org> wrote:
> Hello! Long time no see. I have a customer whose email campaign was
> heavily blocked yesterday by Gmail with the error:
>
>
>
Hello! Long time no see. I have a customer whose email campaign was heavily
blocked yesterday by Gmail with the error:
421 4.7.0 [149.72.90.158 15] Our system has detected that this message is
suspicious due to the very low reputation of the sending domain. To best
protect our users from spam,
53 matches
Mail list logo
