On 2023-05-12 at 16:52:38 UTC-0400 (Fri, 12 May 2023 13:52:38 -0700)
Brandon Long via mailop
is rumored to have said:
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
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.
>
Anyone have a contact? I have someone with an accountant.com address trying to
run a check scam on me.
Mike Hillyer
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
It appears that Bill Cole via mailop
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 with verp/bounce addressing widely in use now, 64 octets
>> just isn't enough these days.
>
>Hogwash. 64 mail-safe
Here's a few prominent services I know of sending from this
54.224.0.0/11 subnet. (Whether or not these are spam in your eyes is up
to you, I'm just noting actual legitimate senders.)
* Amazon Business (no-re...@amazon.com)
* Amazon DE (donotre...@amazon.de)
* Adobe
not yet :D
On Fri, 12 May 2023 19:11:53 +0100 John Devine via mailop
wrote:
> Indeed so I think……….
>
> I would so like to block as you have, any legit mail lost yet?
>
> JD
___
mailop mailing list
mailop@mailop.org
To be fair it sounds like they're providing fine customer service, their
customer is just trash.
On 2023-05-12 12:39, Mary via mailop wrote:
No they haven't, but I don't expect them to do so.
Don't they have the same zero-customer-support policy like every other
major tech company?
On
Indeed so I think……….
I would so like to block as you have, any legit mail lost yet?
JD
> On 12 May 2023, at 18:39, Mary via mailop wrote:
>
>
> No they haven't, but I don't expect them to do so.
>
> Don't they have the same zero-customer-support policy like every other major
> tech
Dňa 12. mája 2023 13:40:14 UTC používateľ Paul Gregg via mailop
napísal:
>4.5.3.1. Size Limits and Minimums
When you read RFC, you MUST read all, not only interesting parts.
Yes, sometime it is hard, but notice the sentence in this section:
Every implementation MUST be able to receive
No they haven't, but I don't expect them to do so.
Don't they have the same zero-customer-support policy like every other major
tech company?
On Fri, 12 May 2023 17:40:18 +0100 John Devine via mailop
wrote:
> Have Amazon commented at all?
>
> JD
Great question, yes authentication is all set and they are at (checking) a
quarantine policy.
On Fri, May 12, 2023 at 12:30 PM Julian Bradfield via mailop <
mailop@mailop.org> wrote:
> On 2023-05-12, Jenny Nespola via mailop wrote:
> > Hope you are well. I was wondering what else I may be
Have Amazon commented at all?
JD
> On 12 May 2023, at 17:28, Mary via mailop wrote:
>
>
> Because all amazon spam seems to originate from within that block.
>
> The decision to block larger blocks than /24 is based on:
>
> - faster and more efficient to block at the firewall level
> - /24
> On 12 May 2023, at 14:40, Paul Gregg via mailop wrote:
>
> I'd like to start a discussion on folks opinions(*) on enforcing
> Envelope Sender/Recipient local-part length limits.
>
> *opinions - because no mail operator seems to agree what it should be.
>
> For context, RFC5321 defines
Because all amazon spam seems to originate from within that block.
The decision to block larger blocks than /24 is based on:
- faster and more efficient to block at the firewall level
- /24 block are just not enough these days
- better than doing cpu intensive content filtering
- covers all
On 2023-05-12, Jenny Nespola via mailop wrote:
> Hope you are well. I was wondering what else I may be missing when
> researching a Gmail/Workspace placement issue. I have a client that
[ snip ]
> Once you engage, the mail will stay in the inbox or if you pull from spam,
> but anyone new (with
Dnia 12.05.2023 o godz. 11:14:25 Jenny Nespola via mailop pisze:
>
> Hope you are well. I was wondering what else I may be missing when
> researching a Gmail/Workspace placement issue. I have a client that
> rebranded with a new domain about 4 months ago (maybe it's 5 now) and from
> day 1 hit
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.
Hogwash. 64 mail-safe octets is adequate for every domain to give a
unique
Hi all!
Hope you are well. I was wondering what else I may be missing when
researching a Gmail/Workspace placement issue. I have a client that
rebranded with a new domain about 4 months ago (maybe it's 5 now) and from
day 1 hit the spam folder. Their IP looks to have changed as well (but
using
I'd like to start a discussion on folks opinions(*) on enforcing
Envelope Sender/Recipient local-part length limits.
*opinions - because no mail operator seems to agree what it should be.
For context, RFC5321 defines local-part (the bit of an envelope address
to the left of the @ in an email
19 matches
Mail list logo
