Re: [mailop] The oligopoly has won.

[Grant Taylor via mailop]

On 9/29/22 9:59 PM, John Levine via mailop wrote:
but nobody's ever had much use for notifications that "yes I delivered 
the mail" even though there's been a spec for that for a long time.


I find that I use "RCPT TO:<...> NOTIFY=SUCCESS" about once a year for 
various reasons.  Usually when I'm trying to confirm that the SMTP path 
between my server and as close to the recipient's server is not 
blatantly failing.  Sometimes I get lucky and find that the message is 
handed off to the LDA.


As such, I can usually rule out interim SMTP channel problems and go to 
the recipient / recipient's administrator and persuade them to look a 
little bit more than they did when offhandedly saying you're smaller 
than us so the problem must be on your end, go a way.  How they actually 
say this varies.


I usually also add ORCPT into the DSN.  Likewise with "MAIL FROM:<...> 
RET=HDRS ENVID=..." because why not fully utilize DSNs if I'm going to 
the trouble of using them.


Aside:  Any time I write a client SMTP engine, I make sure to utilize 
them if I can.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] The oligopoly has won.

[John Levine via mailop]

It appears that Ellenor Agnes Bjornsdottir via mailop 
 said:
>No place for 252 ("I've accepted your message and I will do my best, but
>you'll have to wait on word from the recipient before considering it
>delivered")?

If you look at RFC 5321, you'll see that 252 only applies to the
nearly forgotten VRFY and EXPN commands.

The design of SMTP quite clearly says that if you accept a message, you are 
responsible
for it and you should either deliver it or send back an NDN if not.  I realize 
that
modern practice somewhat deviates from this, but nobody's ever had much use for
notifications that "yes I delivered the mail" even though there's been a spec 
for
that for a long time.

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

Re: [mailop] gmail: Benefit of a generic SPF-record?

[Grant Taylor via mailop]

On 9/29/22 1:42 PM, Jaroslaw Rafa via mailop wrote:
But exactly because TLS is a TLD, which means both bad and good actors 
can register under it, you should not treat a whole TLD (any TLD) 
as a spam source.


The operative /word/ there is "SHOULD".

The operative /concept/ there is that each receiving server is allowed 
to do whatever they want to do.


I've also seen many people talking about banning some of the newer -- 
let's go with -- vanity TLDs outright in order to avoid spam therefrom.


I've also seen many people doing the same thing with IPv6.


You should conside every domain under the TLD individually.


See my operative concept comment above.  }:-)



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] gmail: Benefit of a generic SPF-record?

[Jaroslaw Rafa via mailop]

Dnia 29.09.2022 o godz. 15:39:49 Brandon Long via mailop pisze:
> > But exactly because TLS is a TLD, which means both bad and good actors can
> > register under it, you should not treat a whole TLD (any TLD) as a spam
> > source.
> > You should conside every domain under the TLD individually.
> >
> 
> This feels like a retread, in the absence of enough information to judge a
> specific, one
> falls back to the general.
> 
> A couple messages a day does not a reputation make.

With this approach, a sender that accidentally happens to be under the
"wrong" TLD, cannot build reputation at all. If I'm marked as spam when
sending a couple of messages a day, if I send more messages, things will
only get worse for me, because there will be more messages from me marked as
spam, so I will be confirmed as an actual spammer (despite the fact I'm
not). That will only build negative reputation for me, but I see no way to
build positive one. So something's definitely wrong with this approach.

The most absurd thing for me is that even my replies to messages that I
received from Gmail users, replies that are tied to proper Message-Id: etc.
(so you can verify that I'm actually replying to a message I received from a
Gmail user) are marked as spam and don't reach the recipients inbox.

If your system can't be specific enough to distinguish between different
domains if they are below a certain threshold (with regard to number of
messages sent), then the only sane approach is to treat all messages from
these domains as non-spam by default, unless the domain (but here it must be
that specific domain, not a TLD!) is confirmed to send spam.

In other words, positive reputation should be a default, at least for small
senders. If you are sending spam, then you build negative reputation. Then
of course if you finally stop sending spam, it would take time to rebuild
the reputation, but it should be possible somehow.

But it is just plain wrong to mark messages from a domain as spam right
from the start, because in that case there's no way to build reputation at
all.
-- 
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: Benefit of a generic SPF-record?

[Brandon Long via mailop]

On Thu, Sep 29, 2022 at 12:44 PM Jaroslaw Rafa via mailop 
wrote:

> Dnia 29.09.2022 o godz. 10:33:38 Brandon Long via mailop pisze:
> > The PSL only tells you what's the TLD and what's not, that doesn't mean
> you
> > can't consider
> > a TLD a bad spam source.  There are plenty of those.  Like checking the
> > reputation of a network or ASN over a
> > single IP.
>
> But exactly because TLS is a TLD, which means both bad and good actors can
> register under it, you should not treat a whole TLD (any TLD) as a spam
> source.
> You should conside every domain under the TLD individually.
>

This feels like a retread, in the absence of enough information to judge a
specific, one
falls back to the general.

A couple messages a day does not a reputation make.

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

Re: [mailop] gmail: Benefit of a generic SPF-record?

[Jaroslaw Rafa via mailop]

Dnia 29.09.2022 o godz. 10:33:38 Brandon Long via mailop pisze:
> The PSL only tells you what's the TLD and what's not, that doesn't mean you
> can't consider
> a TLD a bad spam source.  There are plenty of those.  Like checking the
> reputation of a network or ASN over a
> single IP.

But exactly because TLS is a TLD, which means both bad and good actors can
register under it, you should not treat a whole TLD (any TLD) as a spam
source.
You should conside every domain under the TLD individually.
-- 
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: Benefit of a generic SPF-record?

[Jarland Donnell via mailop]

You don't have to insult my intelligence for recognizing that a softfail 
is weak. I never said it was the same thing as neutral, don't put words 
in my mouth. Read the RFC if that's what you're into:


   A "softfail" result is a weak statement by the publishing ADMD that
   the host is probably not authorized.  It has not published a
   stronger, more definitive policy that results in a "fail".

It's weak. It says "probably not authorized" which is to say, if an IP 
doesn't fit the SPF, then ~ definitely DOES NOT instruct the recipient 
to consider it absolutely not authorized.


On 2022-09-29 13:30, Bill Cole via mailop wrote:

On 2022-09-29 at 13:15:54 UTC-0400 (Thu, 29 Sep 2022 12:15:54 -0500)
Jarland Donnell via mailop 
is rumored to have said:

That little ~ is the part that gets me and I think opens it up to any 
IP more than the parts before it.


That reflects a misunderstanding of the SPF specification. '?' and '~'
are NOT equivalent. You can treat them as if they were, if you like,
but that does not change the fact that as defined in the
specification, they are different.

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

Re: [mailop] gmail: Benefit of a generic SPF-record?

[Bill Cole via mailop]

On 2022-09-29 at 13:15:54 UTC-0400 (Thu, 29 Sep 2022 12:15:54 -0500)
Jarland Donnell via mailop 
is rumored to have said:

That little ~ is the part that gets me and I think opens it up to any 
IP more than the parts before it.


That reflects a misunderstanding of the SPF specification. '?' and '~' 
are NOT equivalent. You can treat them as if they were, if you like, but 
that does not change the fact that as defined in the specification, they 
are different.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] gmail: Benefit of a generic SPF-record?

[Gellner, Oliver via mailop]

> Am 29.09.2022 um 15:33 schrieb Stefan Neufeind via mailop :
>
> But does a SPF like
>
>  v=spf1 a mx ~all
>
> have any real benefit?

This SPF record is perfectly legit, there is nothing generic about it. It 
restricts the authorized senders to a few IP addresses and fails for everything 
else.
To optimize it you could replace A and MX with the IP addresses of those 
hostnames to speed up the lookup, but for a small site this is not really 
necessary.

> And if it does, why isn't it sufficient that the domain and ip listed above 
> belong to the legitimate MX? Of course that IP had proper rDNS and all that.
>
> It's becoming more and more crazy with some of the bigger mail-providers out 
> there *sigh*

There’s nothing crazy going on here.
The MX records have no meaning regarding whether a server is allowed to *send* 
email for a domain - thats what another record, the SPF record, is for. Maybe 
someone pointed the MX records of his domain to some spam filtering service, 
which doesn’t mean he wants to authorize this service to send emails on his 
behalf.

—
BR Oliver



dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] gmail: Benefit of a generic SPF-record?

[Brandon Long via mailop]

The PSL only tells you what's the TLD and what's not, that doesn't mean you
can't consider
a TLD a bad spam source.  There are plenty of those.  Like checking the
reputation of a network or ASN over a
single IP.

Brandon

On Thu, Sep 29, 2022 at 10:21 AM Jaroslaw Rafa via mailop 
wrote:

> Dnia 29.09.2022 o godz. 10:02:53 Brandon Long via mailop pisze:
> >
> > Another is the same old PSL issue, rDNS is rarely going to match the
> exact
> > domain, and sub-domain
> > matching can go awry.  Obviously things like DMARC also rely on PSL, so
> it
> > seems unlikely this is the
> > reason.
>
> It's quite funny that you mention PSL, while my almost three year old
> problem with Google marking my messages as spam (and nothing got better
> during that time) seems to indicate that your spam filter messes up
> domains with respect to PSL. Looks like messages from my domain
> (rafa.eu.org) are probably marked as spam because of bad reputation of
> other
> *.eu.org domains. Since eu.org is on PSL, it's basically the same as if
> you
> would mark some example.com domain as spam, despite the fact no spam has
> ever been sent from this particular domain, only because there are spammers
> in other *.com domains...
>
> And nothing has improved in this matter during these three years.
> --
> 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
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] gmail: Benefit of a generic SPF-record?

[Brandon Long via mailop]

On Thu, Sep 29, 2022 at 10:27 AM Jarland Donnell via mailop <
mailop@mailop.org> wrote:

> That little ~ is the part that gets me and I think opens it up to any IP
> more than the parts before it. I always interpret ~ like a shoulder
> shrug, so as to read this:
>
> v=spf1 a mx ~all
>
> Like this in english:
>
> "I will only send mail from my A record or MX record, or pretty much
> whatever man, mail from me might come from anywhere I dunno bro."
>
> It just feels like someone got a little high halfway through their SPF
> record and said "Where does any email come from really man?"
>
> I'm joking around a bit but there's an ounce of truth to it. You should
> always be confident enough in your SPF record to drop the ~ and toss in
> the - instead. It's just so easy to get SPF right.


I would have said before that ~all is what I would recommend, because
messages
get forwarded with their envelope intact in many cases (correctly), and
-all would seem
to say "don't allow that".  In reality, I think places mostly ignore the
all tag completely.
Most large providers have probably been bitten by the too-wide SPF records
getting
abused issue, and so will ignore most of them (does Apple still specify
their entire class A?)
So, +all is just plain out, and -all ignores forwarding... so instead treat
spf like dkim, where
you only consider pass as useful, and fail as "eh".

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

Re: [mailop] gmail: Benefit of a generic SPF-record?

[Jarland Donnell via mailop]

That little ~ is the part that gets me and I think opens it up to any IP 
more than the parts before it. I always interpret ~ like a shoulder 
shrug, so as to read this:


v=spf1 a mx ~all

Like this in english:

"I will only send mail from my A record or MX record, or pretty much 
whatever man, mail from me might come from anywhere I dunno bro."


It just feels like someone got a little high halfway through their SPF 
record and said "Where does any email come from really man?"


I'm joking around a bit but there's an ounce of truth to it. You should 
always be confident enough in your SPF record to drop the ~ and toss in 
the - instead. It's just so easy to get SPF right.


On 2022-09-29 12:02, Brandon Long via mailop wrote:

On Thu, Sep 29, 2022 at 7:32 AM Renaud Allard via mailop
 wrote:


On 9/29/22 15:27, Stefan Neufeind via mailop wrote:

Hi,

I recently came across an email being rejected by gmail.com [1]

with:


This message does not pass authentication checks (SPF and DKIM

both do

not pass). SPF check for [...] does not pass with ip: [...].

That email was not spam but authenticated to the mailserver

mentioned

(the ip given above), which is listed as MX for that domain etc.

There

was no SPF-record at that time. I'm now going to retry with an "as

basic

as possible" SPF-record. But does a SPF like

v=spf1 a mx ~all

have any real benefit? And if it does, why isn't it sufficient

that the

domain and ip listed above belong to the legitimate MX? Of course

that

IP had proper rDNS and all that.


With this kind of SPF record, there is no real benefit, apart from
having an SPF record which basically says: "we can send from any IP
in
the world". So, yes, _maybe_ you wouldn't get the gmail rejection
message, but that doesn't mean your mail will land anywhere nearby
the
inbox. But only google can tell you.


Why would you say this record is "any IP"?  It's only IPs that match
the A and MX records
for the domain, that's a lot more restrictive than +all or some very
wide IP ranges.

Otherwise, agreed that yes, rDNS or just automatically trying a record
like the above as a fallback
is possible, spf is slightly more useful in terms of intent.  One
major difference is in domain ownership,
a company may have rDNS  for their entire fleet of machines, but that
doesn't mean all of them should
be sending mail, and a compromised machine could send mail as the
domain (it's not the only solution to
that problem).  DNS is typically centrally managed, so central control
over who can send mail.

Another is the same old PSL issue, rDNS is rarely going to match the
exact domain, and sub-domain
matching can go awry.  Obviously things like DMARC also rely on PSL,
so it seems unlikely this is the
reason.

Brandon

Links:
--
[1] http://gmail.com
___
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] gmail: Benefit of a generic SPF-record?

[Jaroslaw Rafa via mailop]

Dnia 29.09.2022 o godz. 10:02:53 Brandon Long via mailop pisze:
> 
> Another is the same old PSL issue, rDNS is rarely going to match the exact
> domain, and sub-domain
> matching can go awry.  Obviously things like DMARC also rely on PSL, so it
> seems unlikely this is the
> reason.

It's quite funny that you mention PSL, while my almost three year old
problem with Google marking my messages as spam (and nothing got better
during that time) seems to indicate that your spam filter messes up
domains with respect to PSL. Looks like messages from my domain
(rafa.eu.org) are probably marked as spam because of bad reputation of other
*.eu.org domains. Since eu.org is on PSL, it's basically the same as if you
would mark some example.com domain as spam, despite the fact no spam has
ever been sent from this particular domain, only because there are spammers
in other *.com domains...

And nothing has improved in this matter during these three years.
-- 
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: Benefit of a generic SPF-record?

[Alessandro Vesely via mailop]

On Thu 29/Sep/2022 15:27:57 +0200 Stefan Neufeind via mailop wrote:


I recently came across an email being rejected by gmail.com with:

This message does not pass authentication checks (SPF and DKIM both do not 
pass). SPF check for [...] does not pass with ip: [...].


That email was not spam but authenticated to the mailserver mentioned (the ip 
given above), which is listed as MX for that domain etc. There was no 
SPF-record at that time. I'm now going to retry with an "as basic as possible" 
SPF-record. But does a SPF like


   v=spf1 a mx ~all

have any real benefit? And if it does, why isn't it sufficient that the domain 
and ip listed above belong to the legitimate MX? Of course that IP had proper 
rDNS and all that.



The MX is where you receive mail.  Do you also send from the same interface(s)?

If you know the IPs you use for sending, just list them; for example:
"v=spf1 ip4:91.184.32.3 ip6:2a01:198::3 ~all"


Best
Ale
--








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

Re: [mailop] gmail: Benefit of a generic SPF-record?

[Brandon Long via mailop]

On Thu, Sep 29, 2022 at 7:32 AM Renaud Allard via mailop 
wrote:

>
>
> On 9/29/22 15:27, Stefan Neufeind via mailop wrote:
> > Hi,
> >
> > I recently came across an email being rejected by gmail.com with:
> >
> > This message does not pass authentication checks (SPF and DKIM both do
> > not pass). SPF check for [...] does not pass with ip: [...].
> >
> > That email was not spam but authenticated to the mailserver mentioned
> > (the ip given above), which is listed as MX for that domain etc. There
> > was no SPF-record at that time. I'm now going to retry with an "as basic
> > as possible" SPF-record. But does a SPF like
> >
> >v=spf1 a mx ~all
> >
> > have any real benefit? And if it does, why isn't it sufficient that the
> > domain and ip listed above belong to the legitimate MX? Of course that
> > IP had proper rDNS and all that.
>
> With this kind of SPF record, there is no real benefit, apart from
> having an SPF record which basically says: "we can send from any IP in
> the world". So, yes, _maybe_ you wouldn't get the gmail rejection
> message, but that doesn't mean your mail will land anywhere nearby the
> inbox. But only google can tell you.
>

Why would you say this record is "any IP"?  It's only IPs that match the A
and MX records
for the domain, that's a lot more restrictive than +all or some very wide
IP ranges.

Otherwise, agreed that yes, rDNS or just automatically trying a record like
the above as a fallback
is possible, spf is slightly more useful in terms of intent.  One major
difference is in domain ownership,
a company may have rDNS  for their entire fleet of machines, but that
doesn't mean all of them should
be sending mail, and a compromised machine could send mail as the domain
(it's not the only solution to
that problem).  DNS is typically centrally managed, so central control over
who can send mail.

Another is the same old PSL issue, rDNS is rarely going to match the exact
domain, and sub-domain
matching can go awry.  Obviously things like DMARC also rely on PSL, so it
seems unlikely this is the
reason.

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

Re: [mailop] gmail: Benefit of a generic SPF-record?

[Renaud Allard via mailop]

On 9/29/22 15:27, Stefan Neufeind via mailop wrote:

Hi,

I recently came across an email being rejected by gmail.com with:

This message does not pass authentication checks (SPF and DKIM both do 
not pass). SPF check for [...] does not pass with ip: [...].


That email was not spam but authenticated to the mailserver mentioned 
(the ip given above), which is listed as MX for that domain etc. There 
was no SPF-record at that time. I'm now going to retry with an "as basic 
as possible" SPF-record. But does a SPF like


   v=spf1 a mx ~all

have any real benefit? And if it does, why isn't it sufficient that the 
domain and ip listed above belong to the legitimate MX? Of course that 
IP had proper rDNS and all that.


With this kind of SPF record, there is no real benefit, apart from 
having an SPF record which basically says: "we can send from any IP in 
the world". So, yes, _maybe_ you wouldn't get the gmail rejection 
message, but that doesn't mean your mail will land anywhere nearby the 
inbox. But only google can tell you.


As long as you don't have proper restrictive SPF/DMARC/rDNS, don't 
expect big players to allow your mail enter the inbox.


That doesn't mean you can't try it, after all, it might work.



It's becoming more and more crazy with some of the bigger mail-providers 
out there *sigh*




It's not really new and can even be worse with other "big mail providers".


smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] gmail: Benefit of a generic SPF-record?

[Bill Cole via mailop]

On 2022-09-29 at 09:27:57 UTC-0400 (Thu, 29 Sep 2022 15:27:57 +0200)
Stefan Neufeind via mailop 
is rumored to have said:


Hi,

I recently came across an email being rejected by gmail.com with:

This message does not pass authentication checks (SPF and DKIM both do 
not pass). SPF check for [...] does not pass with ip: [...].


That email was not spam but authenticated to the mailserver mentioned 
(the ip given above), which is listed as MX for that domain etc. There 
was no SPF-record at that time. I'm now going to retry with an "as 
basic as possible" SPF-record. But does a SPF like


  v=spf1 a mx ~all

have any real benefit?


Whether it will help in your specific case with this one provider, only 
they can say.


People have reported that adding a simple SPF record like that has 
worked to get their mail delivered by Google. Whether that will be true 
for you, only Google can say.


And if it does, why isn't it sufficient that the domain and ip listed 
above belong to the legitimate MX?


Because that's all heuristic guessing at the unsure implications of 
non-dependent facts: MX is only an identification of the machine that 
knows how to deliver TO a domain, not the machine authorized to handle 
mail FROM users in the domain.


SPF is explicitly and solely about sending mail and has well-defined 
semantics. No guessing needed.



Of course that IP had proper rDNS and all that.

It's becoming more and more crazy with some of the bigger 
mail-providers out there *sigh*


Yes, but this is not exactly new or particularly 'crazy' for Google.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] gmail: Benefit of a generic SPF-record?

[Stefan Neufeind via mailop]

Hi,

I recently came across an email being rejected by gmail.com with:

This message does not pass authentication checks (SPF and DKIM both do 
not pass). SPF check for [...] does not pass with ip: [...].


That email was not spam but authenticated to the mailserver mentioned 
(the ip given above), which is listed as MX for that domain etc. There 
was no SPF-record at that time. I'm now going to retry with an "as basic 
as possible" SPF-record. But does a SPF like


  v=spf1 a mx ~all

have any real benefit? And if it does, why isn't it sufficient that the 
domain and ip listed above belong to the legitimate MX? Of course that 
IP had proper rDNS and all that.


It's becoming more and more crazy with some of the bigger mail-providers 
out there *sigh*



Kind regards,
 Stefan
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] The oligopoly has won.

[Ellenor Agnes Bjornsdottir via mailop]

No place for 252 ("I've accepted your message and I will do my best, but
you'll have to wait on word from the recipient before considering it
delivered")?

On 9/14/22 15:20, Jaroslaw Rafa via mailop wrote:

Dnia 14.09.2022 o godz. 16:49:58 Thomas Walter via mailop pisze:

If I send someone an email and get a reject, I know they didn't receive it.
It's my job to make sure they get the email then or contact them using other
means.

That's a lot better than Schrödinger's mailbox where you don't know wether
an email got delivered, got overlooked in a spamfolder or - even worse -
blackholed.

A new SMTP response code that would indicate successful delivery, BUT marking
the message as spam, would be helpful.

But of course someone might always argue against it, that this can be abused
by spammers to work around filters...

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

Re: [mailop] Microsoft 365 send spam via high-risk delivery pool (instead of block it)

[Hans-Martin Mosner via mailop]

Am 29.09.22 um 08:19 schrieb Alessio Cecchi via mailop:


I think it is not a correct behavior, if you can identify a message as unwanted 
why do you have to send it anyway?


Often such identification isn't 100% certain (in fact, no spam/ham distinction 
can ever be 100% correct).

Of course, if the message originated from a Microsoft customer it might be more reasonable to return it to the sender 
with an indication of what was considered questionable, but even the decision whether a message was created by the 
customer may be difficult in cases of mail forwarding etc.


Offloading the decision to the recipient at least ensures that no valid e-mail is ever prevented from reaching them, 
which is a (questionable IMO) legal requirement in the EU.


I'd rather prefer if they rejected identified spam instead of delivering it, but then I also want world peace. And a 
pony. With my luck, I'll get none of these.


Cheers,
Hans-Martin

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

[mailop] Microsoft 365 send spam via high-risk delivery pool (instead of block it)

[Alessio Cecchi via mailop]

Hi,

on Microsoft 365 documentations site I found an article where you can read:

"[...] all outbound messages from Microsoft 365 datacenter servers that 
are determined to be spam are sent through the high-risk delivery pool."


https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/high-risk-delivery-pool-for-outbound-messages

So, when Microsoft 365 identify an outbound message as spam don't block 
it but was sent via "the high-risk delivery pool".


I think it is not a correct behavior, if you can identify a message as 
unwanted why do you have to send it anyway? It does not seem to me a 
positive contribution to the cause of a better internet, but only a 
discharge of responsibility on the receiving server.


In any case, some one know what are the IP address in the "high-risk 
delivery pool" of Microsft 365?


Thanks

--
Alessio Cecchi
Postmaster @http://www.qboxmail.it
https://www.linkedin.com/in/alessice
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop