Re: [mailop] What's the point of secondary MX servers?

[Ángel via mailop]

On 2020-12-18 at 15:58 +0100, Jaroslaw Rafa via mailop wrote:
> > SendGrid. They have a webpage that says "We continue to retry
> > messages for up to 72 hours," but they (sometimes?) don't.
> 
> They do for most customers, but for some they don't.
> 
> I remember this issue with password change confirmations on Spotify,
> they were using Sendgrid at that time (don't know if still are?)

Is it a "please input this code to confirm you are the one changing
your password"? That actually makes sense. If the content of the
message is no longer needed before it gets delivered, you could skip it
(why would you queue for a week an OTP which was valid just for 5
minutes?). There is a RFC with a smtp extension for that, even. I guess
Sendgrid api may have as well a parameter to set the maximum time to
attempt delivery.

So there are a few messages which are low-value themselves and where it
is not needed to queue for a long time. For the most part, they SHOULD
be retried, though. It's not even hard to do. If you have a “dumb”
client which is not able to queue and retry itself, simply point it to
an internal MTA (assumed to be always up) and let that one take care of
communicating with the world.
Quoting rfc 5321: “the give-up time generally needs to be at least 4-5
days”

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] GMail 550 5.1.1?

[John Levine via mailop]

In article <20201219223035.ga4...@rafa.eu.org> you write:
>Dnia 19.12.2020 o godz. 16:51:56 John Levine via mailop pisze:
>> Pursuant to our unconditional satisfaction guarantee, please find
>> enclosed a check for 200% of the amount you have paid Gmail to handle
>> your mail.
>
>Please note that not only "Gmail" as understood by the free mail service did
>not work. GSuite and all the paid services didn't work as well. Even these
>used by big corporations. So your bad "joke" simply misfired.

As I would have thought was obvious, the refund was to third parties
who are neither customers nor even Gmail users complaining that Gmail
didn't handle the mail that they sent to Gmail the way they wanted.

If I were paying for Gsuite I would expect a refund but that is a
totally separate issue.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] GMail 550 5.1.1?

[Chris via mailop]

For a couple of years, the Usenet link to/from Australia were magtape 
exchanges on a routine NASA flight out of, if I remember right, NASA 
Ames.  It was piggybacked on the shipment of data to/from joint 
NASA-Australia projects. I used to correspond occasionally with the guy 
involved in doing that.


This would have been from the era when 9600baud and partial T1s via UUCP 
were the bees knees.


You'd ask a question of someone in Australia, and you generally had an 
answer within 3-4 days.


Which led, in part, to the old meme "never underestimate the bandwidth 
of a shipment of magtapes".


Tho, I suppose you'd be hard pressed to do that today even with LTO-6. 
Not that Usenet is that big today.



On 2020-12-19 19:36, Jaroslaw Rafa via mailop wrote:

Dnia 19.12.2020 o godz. 15:52:21 Bob Proulx via mailop pisze:

Plus the SMTP protocol has never tried to be an end user visible
protocol.  Which, if implemented over Avian Carriers, might be
unappealing to the consumer.  Even if the cost is only bird seed.  The
diagrams in RFC 2549 I find the most enjoyable.


A funny story: I actually remember from early days of Internet in my country
something people called "SMTP by train". It was no SMTP actually, but in
case when there was a prolonged link failure between mail servers in two
cities, these guys just made a copy of mail queue from one server on a tape,
took a train to the other city and copied the messages into the queue of the
second server there... Then of course they did the same procedure in the
other direction...



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] GMail 550 5.1.1?

[Jaroslaw Rafa via mailop]

Dnia 19.12.2020 o godz. 15:52:21 Bob Proulx via mailop pisze:
> Plus the SMTP protocol has never tried to be an end user visible
> protocol.  Which, if implemented over Avian Carriers, might be
> unappealing to the consumer.  Even if the cost is only bird seed.  The
> diagrams in RFC 2549 I find the most enjoyable.

A funny story: I actually remember from early days of Internet in my country
something people called "SMTP by train". It was no SMTP actually, but in
case when there was a prolonged link failure between mail servers in two
cities, these guys just made a copy of mail queue from one server on a tape,
took a train to the other city and copied the messages into the queue of the
second server there... Then of course they did the same procedure in the
other direction...
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] GMail 550 5.1.1?

[Bob Proulx via mailop]

Sam Tuke via mailop wrote:
> With Gmail's self filtering folders, for many smaller hosts the
> chances of a message which gets a 250 response code being "received"
> (reach the eyeballs of the intended recipient) is lower than not. So
> 250 says more about Gmail internals (e.g. the message wasn't
> rejected by the first gatekeeper) than it does about successful
> delivery. End users still complain that messages weren't delivered,
> and we have to investigate each time.

The 250 code you refer to is the SMTP handshake and says only that the
mail was transferred successfully between two mail relays.  It's no
different than sending an ACK after receiving a FIN in a TCP
connection.  It's a transmission protocol state transition indication.

The SMTP response only applies to MTAs, mail transfer agents.  It does
not apply to MUAs, mail user agents.  There is no ability and has
never been an ability anywhere at any time to know that someone has
read the message.

Plus the SMTP protocol has never tried to be an end user visible
protocol.  Which, if implemented over Avian Carriers, might be
unappealing to the consumer.  Even if the cost is only bird seed.  The
diagrams in RFC 2549 I find the most enjoyable.

Bob
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] GMail 550 5.1.1?

[Jaroslaw Rafa via mailop]

Dnia 19.12.2020 o godz. 16:51:56 John Levine via mailop pisze:
> Pursuant to our unconditional satisfaction guarantee, please find
> enclosed a check for 200% of the amount you have paid Gmail to handle
> your mail.

Please note that not only "Gmail" as understood by the free mail service did
not work. GSuite and all the paid services didn't work as well. Even these
used by big corporations. So your bad "joke" simply misfired.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] nolisting, was What's the point of secondary MX servers?

[Chris via mailop]

On 2020-12-19 16:43, John Levine via mailop wrote:

In article <12329a9a-11a7-eda4-c88a-3dc352aea...@spamtrap.tnetconsulting.net> 
you write:


On 12/18/20 12:29 PM, John Levine via mailop wrote:

As I recall some sites were getting stuck on the nolist host for
every message.


Odd.

Perhaps it has something to do with the type of nolisting.  Did you have
something listening on the IP address?  Or was it reserved with nothing
there?


I think it was sending resets but as I said, it was a while ago.


Back in the day, a number of servers were known to, uh, function 
suboptimally when presented with various things.


I think the original unpatched qmail had one or two bits of weirdness 
about MX lookups and limited retries.  You might remember the details.


Exchange at one point was treating a "550" after a DATA as "hit me again 
ASAP".  In one case 1.5 million retries in 8 hours.


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] GMail 550 5.1.1?

[John Levine via mailop]

In article <0ea1d827-98d8-761d-cac4-4be972126...@lightmeter.io> you write:
>That's nice to know, but the fact is that messages accepted by Gmail sometimes 
>disappear without a trace. No
>doubt that the systems involved on your side are massive and complex, but that 
>shouldn't be our problem as
>indie hosts.

Pursuant to our unconditional satisfaction guarantee, please find
enclosed a check for 200% of the amount you have paid Gmail to handle
your mail.

Sheesh.

R's,
John

PS: 250 SMTP codes only mean that the recipient system will do
something with the message.  It has never meant that anyone will see
it or read it or act on it.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] What's the point of secondary MX servers?

[John Levine via mailop]

In article <142c9278-dfe9-4dfc-70ab-50dc27264...@linkedin.com> you write:
>
>It may not be as common, but I don't see a reason to remove the option.

Oh, I agree, it's not going away and it usually doesn't hurt (much).

In the past I have done surveys of mail servers to see what features they have,
such as 8BITMIME (all of them now) and SMTPUTF8 (not many other than Gmail and 
MS.)

The question is whether it's also worth testing the lower priority MX.
My position is no, since the vast majority of mail, at least non-spam mail,
goes through the highest priority ones.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] nolisting, was What's the point of secondary MX servers?

[John Levine via mailop]

In article <12329a9a-11a7-eda4-c88a-3dc352aea...@spamtrap.tnetconsulting.net> 
you write:
>
>On 12/18/20 12:29 PM, John Levine via mailop wrote:
>> As I recall some sites were getting stuck on the nolist host for 
>> every message.
>
>Odd.
>
>Perhaps it has something to do with the type of nolisting.  Did you have 
>something listening on the IP address?  Or was it reserved with nothing 
>there?

I think it was sending resets but as I said, it was a while ago.

-- 
Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] GMail 550 5.1.1?

[Robert L Mathews via mailop]

On 12/19/20 9:27 AM, Sam Tuke via mailop wrote:
> That's nice to know, but the fact is that messages accepted by Gmail 
> sometimes disappear without a trace.

In my experience of investigating a few of these in detail, this is not
actually the case. Instead, what happens is that the Gmail interface
makes people unable to find it, because users don't realize that
searching doesn't search the Spam or Trash folders, *even with the "All
Mail" option selected*.

If you can reliably get people to follow the instructions here, they
usually find it:

 https://blog.tigertech.net/posts/searching-the-gmail-spam-folder/

-- 
Robert L Mathews, Tiger Technologies, http://www.tigertech.net/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] GMail 550 5.1.1?

[Sam Tuke via mailop]

On 18/12/2020 23:00, Brandon Long wrote:
> So, returning 250 OK when delivering a message to spam is bad form
> now?  Or a 4xx response to potential spam that you're not quite sure
> about?

With Gmail's self filtering folders, for many smaller hosts the chances of a 
message which gets a 250 response code being "received" (reach the eyeballs of 
the intended recipient) is lower than not. So 250 says more about Gmail 
internals (e.g. the message wasn't rejected by the first gatekeeper) than it 
does about successful delivery. End users still complain that messages weren't 
delivered, and we have to investigate each time.

> Also, there is no provision in our spam system for dropping mail,
> it's reject, deliver or bounce... I guess workspace does add
> administrator actions like admin quarantine or change destination.

That's nice to know, but the fact is that messages accepted by Gmail sometimes 
disappear without a trace. No doubt that the systems involved on your side are 
massive and complex, but that shouldn't be our problem as indie hosts.

Sam.

> On Fri, Dec 18, 2020, 12:11 PM Sam Tuke via mailop  > wrote:
> 
> FWIW, partly inspired by this thread, I blogged about the week's
> Gmail fun here: 
> https://lightmeter.io/googledown-happens-every-day-for-mailops-admins/
> 
>
>  Sam.
> 
> On 16/12/2020 15:34, Dr. Christopher Kunz via mailop wrote:
>> Am 15.12.20 um 00:56 schrieb Bez Thomas via mailop:
>>> Anyone else seeing repeated, but intermittent, 550-5.1.1s from
>>> Gmail for valid addresses?
>>> 
>>> Diagnostic-Code: smtp; 550-5.1.1 The email account that you tried
>>> to reach does not exist. Please try 550-5.1.1 double-checking the
>>> recipient's email address for typos or 550-5.1.1 unnecessary
>>> spaces. Learn more at 550 5.1.1
>>> https://support.google.com/mail/?p=NoSuchUser
>>> 
>>> 
>> FWIW, this was acknowledged and marked as resolved by Google now
>> [1], and has been discussed elsewhere [2].
>> 
>> [1]
>> https://www.google.com/appsstatus#hl=en=issue=1=a8b67908fadee664c68c240ff9f529ab
>> 
>
>> 
> [2] https://news.ycombinator.com/item?id=25435916
> 
>> 
>> Best regards,
>> 
>> 
>> --ck
>> 
>> 
>> ___ 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 mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Why 5xx? (was: GMail 550 5.1.1)

[Chris via mailop]

On 2020-12-15 18:04, Chris Wedgwood via mailop wrote:

things break, it happens...

but why 5xx (vs 4xx) in this case?

this means means emails are being lost, some of won't/can't be resent
and recovered

with 4xx most of them would be delivered once things come right

the confidence in a hard-bounce in this instance seems misplaced


Well, yes.  But receivers get  pissed off if you 
continuously ignore 5xx "just because I can't trust them".  I've been 
known to firewall such abusers regardless of whether their email is 
spam/abusive.  The retries are THEMSELVES are abusive.


You don't want receivers  pissed off at you.  You 
really don't even want large receivers to NOTICE you.  If they're forced 
to notice you, you lose.


The mailing industry has come up with fairly reasonable compromises. 
Including exponential backoff, a heavily limited number of retries, or 
my favourite: simply taking them at face value, but you don't have to 
remove the recipient from the original list until a threshold number of 
consequtive 5xxs occur over a reasonably long period of time with 
different emails.


I don't know the precise details of, say, the M3AAWG senders WG's 
working papers recommend as BCP.  But say, 5 5xxs from 5 different 
emails over a week or more, sounds like a good starting point for list 
removal.


Yes, some email will get lost.  Personal high-importance email will get 
through anyway (perhaps over the phone or whatever).  But it's still 
better than being firewalled.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] GMail 550 5.1.1?

[Brandon Long via mailop]

So, returning 250 OK when delivering a message to spam is bad form now?  Or
a 4xx response to potential spam that you're not quite sure about?



Also, there is no provision in our spam system for dropping mail, it's
reject, deliver or bounce...
I guess workspace does add administrator actions like admin quarantine or
change destination.


Brandon

On Fri, Dec 18, 2020, 12:11 PM Sam Tuke via mailop 
wrote:

> FWIW, partly inspired by this thread, I blogged about the week's Gmail fun
> here:
> https://lightmeter.io/googledown-happens-every-day-for-mailops-admins/
>
> Sam.
>
> On 16/12/2020 15:34, Dr. Christopher Kunz via mailop wrote:
> > Am 15.12.20 um 00:56 schrieb Bez Thomas via mailop:
> >> Anyone else seeing repeated, but intermittent, 550-5.1.1s from Gmail
> for valid addresses?
> >>
> >> Diagnostic-Code: smtp; 550-5.1.1 The email account that you tried to
> reach does not exist. Please try
> >> 550-5.1.1 double-checking the recipient's email address for typos or
> >> 550-5.1.1 unnecessary spaces. Learn more at
> >> 550 5.1.1  https://support.google.com/mail/?p=NoSuchUser
> >>
> > FWIW, this was acknowledged and marked as resolved by Google now [1],
> and has been discussed elsewhere [2].
> >
> > [1]
> https://www.google.com/appsstatus#hl=en=issue=1=a8b67908fadee664c68c240ff9f529ab
> > [2] https://news.ycombinator.com/item?id=25435916
> >
> > Best regards,
> >
> >
> > --ck
> >
> >
> > ___
> > 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 mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop