Since on the topic of SendGrid..

Received: from dhl.com (unknown)
        by geopod-ismtpd-2-1 (SG) with ESMTP
        id yXjQUIVNTmWUp86G27YZTw
        for <REDACCTED>;
        Tue, 05 May 2020 10:02:57.886 +0000 (UTC)
From: DHL Express <expr...@dhl.com>
Subject: Shipment Arrival Notice.
Date: Tue, 05 May 2020 10:02:57 +0000 (UTC)
Message-ID: <20200505100257.58c63efbca795...@dhl.com>
MIME-Version: 1.0
X-SG-EID:

=?us-ascii?Q?Fty1fbakBjfkMnPdNSS4UpmkoEOMkDriB8B3kSQUjCzRogyCEiG1y0V8I5N3J4?=
 =?us-ascii?Q?Y=2FMd=2F0SFVzCTWMExjNhU9h6pIlyK51PQJ=2FVJLye?=
 =?us-ascii?Q?RmHv4lJals+LEOvb4dhaYhRi0UPG27bJ=2FJA5mqh?=
 =?us-ascii?Q?VL0Nx9J=2FyaWQ+bIzekwAAGSkhnpeyO+imjI0Cgh?=
 =?us-ascii?Q?r7cfzn2kmMSVsOUIPudnngC0yrk3M=2F80HBjUiIy?=
 =?us-ascii?Q?Wl1Av6MSMteTs=2FjUoR3TVyk006pkGBREAMe4gdV?=
 =?us-ascii?Q?7+1=2F+mc9MUFtHbXdptHbg=3D=3D?=

I don't even think they are trying to stop outbound phishing any more..

This is a little too obvious, and while historically SendGrid ran a tight ship, and got a little lee way from spam auditors.. it's getting very bad, and going on for too long.. risking loosing any preferential treatment..

Overnite..

149.72.1.84         (M)           5   wrqvhkrq.outbound-mail.sendgrid.net
149.72.24.42                      2   wrqvkvnx.outbound-mail.sendgrid.net
   149.72.24.51                   1   wrqvkvpp.outbound-mail.sendgrid.net
149.72.25.142                     7   wrqvkwvz.outbound-mail.sendgrid.net
149.72.43.171                     9   wrqvnbxb.outbound-email.sendgrid.net
149.72.58.101                     3   wrqvpxsr.outbound-email.sendgrid.net
149.72.63.131       (RS)          3   wrqvpfvp.outbound-email.sendgrid.net
   149.72.63.135                 50   wrqvpfvt.outbound-email.sendgrid.net
   149.72.63.193                  6   wrqvpfck.outbound-email.sendgrid.net
149.72.134.56       (M)           1   o2.ptr4806.marketing.sg.getweave.com
149.72.146.9        (M)           1   wrqvwnhw.outbound-mail.sendgrid.net
149.72.163.111                    4   wrqvxpsf.outbound-mail.sendgrid.net
149.72.185.201                    1   wrqvbwcw.outbound-mail.sendgrid.net
149.72.194.224                    3   o1.sg.intherooms.com
149.72.219.45                     6   wrqvdbnd.outbound-mail.sendgrid.net
149.72.224.183      (RS)          2   wrqvzhbt.outbound-mail.sendgrid.net
149.72.226.67                     5   wrqvznqp.outbound-mail.sendgrid.net
149.72.227.4                     50   wrqvzphq.outbound-mail.sendgrid.net
149.72.243.74                     5   wrqvfpqx.outbound-mail.sendgrid.net
   149.72.243.152                 1   wrqvfpwv.outbound-mail.sendgrid.net





On 2020-05-05 6:31 a.m., Jaroslaw Rafa via mailop wrote:
Dnia  5.05.2020 o godz. 08:32:43 Michael Orlitzky via mailop pisze:

That message was never retried, even though this page says you'll retry
for 72 hours:

   https://sendgrid.com/docs/glossary/deferrals/

That sample is fresh in my mind, but it's not a unique problem. We do
pre-queue scanning and sometimes you're just gonna get a busy signal.
We'd all love it if you could re-send at least once per the RFC so that
people will stop calling us about lost messages =)

I have also seen previously several times that Sendgrid did not retry.
However, I've also seen cases when Sendgrid did retry properly. I wonder if
it depends on the sender/customer. Maybe they retry when sending messages
for some customers and don't retry when sending for other ones?

Personally I had a slightly different problem with Sendgrid Sometimes when
they retry, they retry immediately (without any noticeable delay), and each
time connect from a different IP address. After only a small number of such
unsuccessful retries, they give up. Again, it happens only for particular
senders and not for others.

Retrying immediately when you get a 4xx makes no sense in my opinion,
because if 4xx response is caused by some issue on the receiving end, you
couldn't expect that the issue will go away immediately once you retry.
Usually it takes some time to resolve the issue, so the sender should
implement reasonable delays between retries.

Using a different IP address for each retry makes it also impossible for the
message to go past greylisting for the recipients who are using it, as
greylisting expects retry from the same IP address as the original attempt
to send the message (also, greylisting expects a reasonable delay before
retry as well). (Please, don't debate now about greylisting itself and
whether it should be used or not. At least it has it's use against botnet
spam).

A few years ago I ran into this issue and it was an important transactional
message, so I try to report it to Sendgrid via some form on their website
(sorry, I don't remember details, quite a long time has passed), but it
seemed evident that the person responding to me didn't know what I'm talking
about and what greylisting is at all - he or she was referring me to
documents on their website that had nothing to do with the issue - so I gave
up.




--
"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://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Reply via email to