On 25 Jul 2022, at 17:11, Laura Atkins via mailop wrote:
> On 25 Jul 2022, at 15:49, Luis E. Muñoz via mailop wrote:
>> In the current state of affairs, ESPs presume they know more than the
>> receivers, so they keep trying to send. Since the ESPs essentially disregard
>> the 5xx codes using the
On 25 Jul 2022, at 11:00, Laura Atkins via mailop wrote:
>> In the current state of affairs, ESPs presume they know more than the
>> receivers, so they keep trying to send. Since the ESPs essentially disregard
>> the 5xx codes using the line of reasoning that you described,
>
> The ESPs are not
> On 25 Jul 2022, at 15:49, Luis E. Muñoz via mailop wrote:
>
> On 24 Jul 2022, at 4:38, Laura Atkins via mailop wrote:
>
>> We’re trying to pull ‘what to do with a completely different message that
>> might be sent in the future, possibly by a completely different sender' out
>> of a signal
On 23 Jul 2022, at 4:17, Laura Atkins via mailop wrote:
> I agree, it would have been nice if the authors of 821 and 822 had considered
> this use case and provided us with semantics. Unfortunately, the semantics
> described in those RFCs (and their successors) only talk about what to do
> with
On 24 Jul 2022, at 4:38, Laura Atkins via mailop wrote:
> We’re trying to pull ‘what to do with a completely different message that
> might be sent in the future, possibly by a completely different sender' out
> of a signalling system that was never designed to convey that signal. And,
> yes, e
On 24 Jul 2022, at 22:09, Ángel via mailop wrote:
> Now, if we instead have the hash bbbaa1af939a01d0e22286c63827d936
> If you can hash multiple emails until finding who that refers to, then
> it's equivalent to the email. But if it is also the hash of other email
> addresses jsmith@hotmail.exampl
On 7/23/2022 1:17 AM, Laura Atkins via mailop wrote:
On 23 Jul 2022, at 05:18, Bill Cole via mailop wrote:
On 2022-07-22 at 12:45:18 UTC-0400 (Fri, 22 Jul 2022 12:45:18 -0400)
Luis E. Muñoz via mailop
is rumored to have said:
On 22 Jul 2022, at 11:49, Laura Atkins via mailop wrote:
I ques
Dnia 25.07.2022 o godz. 04:09:14 Ángel via mailop pisze:
>
> Now, if we instead have the hash bbbaa1af939a01d0e22286c63827d936
> If you can hash multiple emails until finding who that refers to, then
> it's equivalent to the email.
IANAL as well, but if you want to hash multiple emails to find th
>>whereas press@ec.europa.eｕ would not.
There have been cases where a role based email like that have been considered
being personal details in case of only one person having access to the mailbox.
This on the basis that there can be collected information (IP-adresses and
such) from other partie
On 2022-07-22 at 16:20 -0400, Luis E. Muñoz wrote:
> Going back to the example of an ESP, does the hash of the email
> address equate the email address as per GDPR?
IANAL, but...
GDPR is all about being able to identify someone, even if that would
require help from someone else.
So, the email
> On 23 Jul 2022, at 20:34, John Levine via mailop wrote:
>
> It appears that Bill Cole via mailop
> said:
>> If only we had a framework for error codes in SMTP that carry useful
>> semantics...
>
> We do. That's what the enhanced error codes are for. See RFCs 1893 and
> 5248. A lot of them
On 2022-07-23 at 09:08:17 UTC-0400 (Sat, 23 Jul 2022 15:08:17 +0200)
Jaroslaw Rafa via mailop
is rumored to have said:
Dnia 23.07.2022 o godz. 15:25:43 Atro Tossavainen via mailop pisze:
Ideally, a SMTP return code should differentiate the reason for
rejection.
There should be a different code
On 2022-07-23 at 15:34:39 UTC-0400 (23 Jul 2022 15:34:39 -0400)
John Levine via mailop
is rumored to have said:
It appears that Bill Cole via mailop
said:
If only we had a framework for error codes in SMTP that carry useful
semantics...
We do. That's what the enhanced error codes are for. S
On 2022-07-23 at 04:17:30 UTC-0400 (Sat, 23 Jul 2022 09:17:30 +0100)
Laura Atkins via mailop
is rumored to have said:
On 23 Jul 2022, at 05:18, Bill Cole via mailop
wrote:
[...]
If only we had a framework for error codes in SMTP that carry useful
semantics...
I agree, it would have been ni
It appears that Bill Cole via mailop
said:
>If only we had a framework for error codes in SMTP that carry useful
>semantics...
We do. That's what the enhanced error codes are for. See RFCs 1893 and
5248. A lot of them are quite informative, e.g. 5.2.2 mailbox full,
5.7.13 user account disabled,
Dnia 23.07.2022 o godz. 15:25:43 Atro Tossavainen via mailop pisze:
> > Ideally, a SMTP return code should differentiate the reason for rejection.
> > There should be a different code for non-existing user, technical problems
> > (like mailbox full) or policy-based reject.
>
> You know, they actua
> Ideally, a SMTP return code should differentiate the reason for rejection.
> There should be a different code for non-existing user, technical problems
> (like mailbox full) or policy-based reject.
You know, they actually did think of that.
https://datatracker.ietf.org/doc/html/rfc5321#section-
Dnia 23.07.2022 o godz. 09:17:30 Laura Atkins via mailop pisze:
>
> Consider the case where Microsoft spits out a incorrect and false 550 user
> unknown (which happens every couple years). What you’re suggesting is
> that when this happens the next time, Gmail block every gmail user from
> ever s
Dnia 22.07.2022 o godz. 20:10:35 Atro Tossavainen via mailop pisze:
>
> Indeed if, say, an address doesn't exist, it doesn't exist whether the
> sender is X or Y.
>
> Also, if the mail platform rejects mail from the sender's IPs or domains,
> it will probably do that for X and Y alike.
Ideally,
> Talking about anti-fraud, anti-spam at self-service ESP level, that's
What an excellent writeup. Thank you Simon for this!
--
Atro Tossavainen, Founder, Partner
Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635)
Tallinn, Estonia
tel. +372-5883-4269, http://www.koliloks.eu/
__
> > I would love a way to give those addresses (in a hashed form) to ESPs
> > saying "Look, if somsone is sending to those, it's a bogus list and does
> > not pass muster, and you should reject the customer".
> >
> > I'd love a way to put those addresses in the DNS as a similar flag. "Do
> > no
> On 23 Jul 2022, at 05:18, Bill Cole via mailop wrote:
>
> On 2022-07-22 at 12:45:18 UTC-0400 (Fri, 22 Jul 2022 12:45:18 -0400)
> Luis E. Muñoz via mailop
> is rumored to have said:
>
>> On 22 Jul 2022, at 11:49, Laura Atkins via mailop wrote:
>>
This would allow the ESP to quickly "fa
> I would love a way to give those addresses (in a hashed form) to ESPs saying
> "Look, if somsone is sending to those, it's a bogus list and does not pass
> muster, and you should reject the customer".
>
> I'd love a way to put those addresses in the DNS as a similar flag. "Do not
> allow thi
> If we agree that IP addresses, email addresses and real names are all PII as
> per GDPR, your example is comparable to Cloudflare.
The idea that IP addresses could be personal data has always blown my
mind, but the GDPR does classify it as such.
> The end-user browsing a website is sending PII
> On Jul 23, 2022, at 01:14, Hans-Martin Mosner via mailop
> wrote:
>
> 23. Juli 2022 00:54, "Atro Tossavainen via mailop"
> schrieb:
>
>> Er, I think you mean
>>
>> https://msbl.org/ebl.html
>
> Yeah, basically that, except that i'm thinking of a somewhat wider scope by
> also covering
23. Juli 2022 00:54, "Atro Tossavainen via mailop" schrieb:
> Er, I think you mean
>
> https://msbl.org/ebl.html
Yeah, basically that, except that i'm thinking of a somewhat wider scope by
also covering compromised mailboxes, which gets closer to the PII danger zone
as those woould belong to
On 2022-07-22 at 12:45:18 UTC-0400 (Fri, 22 Jul 2022 12:45:18 -0400)
Luis E. Muñoz via mailop
is rumored to have said:
On 22 Jul 2022, at 11:49, Laura Atkins via mailop wrote:
This would allow the ESP to quickly "fail" the API request to send
to that email address. There are other metrics tha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Wed, 2022-07-20 at 12:41 -0600, Brie via mailop wrote:
> It's still going on even though it was 'being looked into'.
Fixed here by blacklisting the DKIM signature from zoom.us
-BEGIN PGP SIGNATURE-
iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaK
Hans-Martin Mosner wrote:
> Especially in the area of freemailer spam (and somewhat ESP spam, of course),
> hashes of spammy mail senders could be used to share reputation among mailops
> without handling actual e-mail addresses.
Er, I think you mean
https://msbl.org/ebl.html
which was presen
22. Juli 2022 22:20, "Luis E. Muñoz via mailop" schrieb:
> Going back to the example of an ESP, does the hash of the email address
> equate the email address as
> per GDPR?
This probably reaches well into the area of legal expertise and may therefore
be off-topic here, but it would be very int
On 22 Jul 2022, at 13:10, Atro Tossavainen via mailop wrote:
[✄ but thoroughly read]
> Becoming a data controller entails needing a legitimate basis for
> processing the personal data of the customer's customers, with whom
> the ESP does not have any kind of a direct business relationship so
> it
On 7/22/22 10:57 AM, Robert L Mathews via mailop wrote:
I have an bad example of this. My company opened a
thousands-of-dollars-a-year account with a large company, and apparently
this company does all their transactional mailing through a certain
well-known ESP.
I got none of it, and nobody
> I got none of it, and nobody could figure out why for a while. It
> finally turned out that the ESP had added our entire domain name to
> some sort of global blocklist they have, solely based on my
> complaints that the ESP was letting their customers repeatedly send
> spam to our role addresses
Lem said:
> I question your assertion that "bounces for X sender doesn’t mean that it
> shouldn’t be mailed for Y sender".
Indeed if, say, an address doesn't exist, it doesn't exist whether the
sender is X or Y.
Also, if the mail platform rejects mail from the sender's IPs or domains,
it will p
On 7/22/22 4:31 AM, Laura Atkins via mailop wrote:
I’ll point out, this isn’t an ESP only problem. Two of the biggest
sources of spam right now are O365 and Google IP addresses. They are
actually a bigger problem in my (mostly unfiltered for reasons) inbox
than any ESP.
That is an unders
On 7/22/22 8:49 AM, Laura Atkins via mailop wrote:
That’s normal practice as far as I’m aware. If an address bounces the
ESP prevents the sender from mailing to it in the future. There are some
ESPs that don’t (and they know how I feel about their practices). I’ve
also heard complaints from ISP
On 22 Jul 2022, at 11:49, Laura Atkins via mailop wrote:
>> This would allow the ESP to quickly "fail" the API request to send to that
>> email address. There are other metrics that could be tied into those
>> addresses and used to provide a more expedite response to the caller, which
>> incide
Dňa 22. júla 2022 15:49:08 UTC používateľ Laura Atkins via mailop
napísal:
>In many, many cases the issue is that other customers are mailing to the same
>address - and just because an address bounces for X sender doesn’t mean that
>it shouldn’t be mailed for Y sender. One clear example is whe
> On 22 Jul 2022, at 16:02, Luis E. Muñoz via mailop wrote:
>
> On 22 Jul 2022, at 6:31, Laura Atkins via mailop wrote:
>
>> I’m agreeing there is a problem with ESPs and have said so to ESPs
>> individually and as a group over the last few weeks.
>
> Something that I don't see mentioned oft
On 22 Jul 2022, at 6:31, Laura Atkins via mailop wrote:
> I’m agreeing there is a problem with ESPs and have said so to ESPs
> individually and as a group over the last few weeks.
Something that I don't see mentioned often enough and that would help, is to
retain records of bounces—even of hash
Hi Laura, *!
/
The ESPs are interested in sender reputation. But, in this context, reputation
means “Our mail gets accepted at the ISPs”. In that context their reputation is
fine. They’re not being blocked. Specific customers may have delivery problems,
but a lot of the modern machine learning
> On 22 Jul 2022, at 12:22, Simon Arlott via mailop wrote:
>
> On 22/07/2022 10:21, Laura Atkins via mailop wrote:
>>> After that there should be an integrated opt-in process to verify any
>>> new email address for that ESP customer's list.
>>
>> While this sounds simple and like a no-brainer,
On 22/07/2022 10:21, Laura Atkins via mailop wrote:
>> After that there should be an integrated opt-in process to verify any
>> new email address for that ESP customer's list.
>
> While this sounds simple and like a no-brainer, it doesn’t account for how
> complex many companies email programs ar
> On 22 Jul 2022, at 11:13, Slavko via mailop wrote:
>
> Ahoj,
>
> Dňa Fri, 22 Jul 2022 10:21:44 +0100 Laura Atkins via mailop
> napísal:
>
>> ESPs have many, many problems, but the fixes being suggested here on
>> mailop are overly simplistic and evidence a lack of conceptual
>> understandi
Ahoj,
Dňa Fri, 22 Jul 2022 10:21:44 +0100 Laura Atkins via mailop
napísal:
> ESPs have many, many problems, but the fixes being suggested here on
> mailop are overly simplistic and evidence a lack of conceptual
> understanding of how bulk email is sent in 2022.
Sure, complex things has complex
Am 22. Juli 2022 11:34:16 schrieb Laura Atkins via mailop :
ESPs have many, many problems, but the fixes being suggested here on mailop
are overly simplistic and evidence a lack of conceptual understanding of
how bulk email is sent in 2022.
Suggested technical fixes are certainly too simpl
>>> The basic problem is allowing an ESP customer to import a list that
>>> existed before the customer became a customer of this ESP. I can't
>>> think of an ESP that would not allow that.
>>
>> I saw this again as someone replied to it.
>>
>> Sadly, there is at least one legitimate reasons to
On 21/07/2022 10:01, Andrew C Aitchison via mailop wrote:
> On Sun, 9 Jan 2022, Atro Tossavainen via mailop wrote:
>
>> The basic problem is allowing an ESP customer to import a list that
>> existed before the customer became a customer of this ESP. I can't
>> think of an ESP that would not allow
> Many of the ESPs that we certify will require senders with certain types of
> lists (size, industry, etc.) to reconfirm a percentage of their list upon
> upload. And make no mistake, good ESPs scan uploaded lists for the same
> things as do list-washi...er..."list hygiene" services.
Anything
> On Sun, 9 Jan 2022, Atro Tossavainen via mailop wrote:
>
> The basic problem is allowing an ESP customer to import a list that
> existed before the customer became a customer of this ESP. I can't
> think of an ESP that would not allow that.
Many of the ESPs that we certify will require sender
On Sun, 9 Jan 2022, Atro Tossavainen via mailop wrote:
The basic problem is allowing an ESP customer to import a list that
existed before the customer became a customer of this ESP. I can't
think of an ESP that would not allow that.
I saw this again as someone replied to it.
Sadly, there is
> Sadly, there is at least one legitimate reasons to allow this:
> how else could a customer change ESP ?
There is that. But since the new ESP has no immediate way of knowing
anything about the legitimacy of the uploaded list, the problem remains.
--
Atro Tossavainen, Chairman of the Board
Infin
On Wed, Jul 20, 2022 at 12:41:53PM -0600, Brie via mailop wrote:
> So, hey, yeah, Sendgrid and Zoom...
>
> It's still going on even though it was 'being looked into'.
It is. But I looked at the amount of .zoom.us stuff in all the SendGrid
output in our traps from January to June and the trend is
So, hey, yeah, Sendgrid and Zoom...
It's still going on even though it was 'being looked into'.
Why do you not respect permanent errors when delivering? My system is
rejecting the mails, so Sendgrid's systems should be marking the mails
as undeliverables and removing the address or flagging th
> Yep, I know you, Sendgrid, told me that you'd be working on it with
> Zoom. And, as expected, nothing ever happened and they still keep
> coming.
About 0.3% of the spams that Koli-Lõks spamtraps got from SendGrid
in December 2021 matched .zoom.us.
It's large enough to be noticeable, but nothin
On 09/01/2022 13:44, Brie via mailop wrote:
Hi Sendgrid and Zoom,
We've been over this before, multiple times... But alas, it looks like
that you neither of you seem to care a single bit about your services
being used to send spams that can't be unsubscribed from.
Yep, I know you, Sendgrid
Hi Sendgrid and Zoom,
We've been over this before, multiple times... But alas, it looks like
that you neither of you seem to care a single bit about your services
being used to send spams that can't be unsubscribed from.
Yep, I know you, Sendgrid, told me that you'd be working on it with
Zo
57 matches
Mail list logo
