Re: [mailop] fastmail and sender score snafu

[Louis Laureys via mailop]

I believe they meant users changing their mx for an existing domain, when moving
to fastmail for example. Not necessarily a new domain, though I guess they can't
really differentiate those technically. So the policy would also apply to new
domains. Not entirely sure that this is the solution, but I get it.

Louis


Op dinsdag 10 oktober 2023 om 12:25, schreef Alessandro Vesely via mailop:

> On Mon 09/Oct/2023 08:23:33 +0200 Robert Mueller via mailop wrote:
> > >> I see that current setup might be useful in case some user changes MX >>
> before the domain is activated at Fastmail, in which case giving 4xx >> could
> make sense. But it is not right to report such re-tries to sender >> score as
> attempts to deliver to non-existing users.
> > > Yes, this is why we 4xx rather than 5xx email sent to an unconfigured
> domain. Many inexperienced email users aren't sure exactly what order to
> change or set things up in and we've seen users lose email before because they
> changed the MX records before adding their domain at Fastmail. The 4xx
> response reduces the chance of lost email.
> 
> That's bad.
> 
> First, nobody sends an important mail to a new domain without double checking
> its delivery. It is very reasonable to loose a few test messages when you set
> a new domain up.
> 
> By 4xx any unconfigured domain, a warning for delayed email can take hours and
> several attempts. A 5xx would result in an immediate DSN, which is much better
> in case of mistyping.
> 
> Best
> Ale
> --
> 
> ___
> mailop mailing list
> mailop@mailop.org [mailop@mailop.org]
> https://list.mailop.org/listinfo/mailop
> [https://list.mailop.org/listinfo/mailop]___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] fastmail and sender score snafu

[Alessandro Vesely via mailop]

On Mon 09/Oct/2023 08:23:33 +0200 Robert Mueller via mailop wrote:


I see that current setup might be useful in case some user changes MX 
before the domain is activated at Fastmail, in which case giving 4xx 
could make sense. But it is not right to report such re-tries to sender 
score as attempts to deliver to non-existing users.


Yes, this is why we 4xx rather than 5xx email sent to an unconfigured domain. 
Many inexperienced email users aren't sure exactly what order to change or set 
things up in and we've seen users lose email before because they changed the MX 
records before adding their domain at Fastmail. The 4xx response reduces the 
chance of lost email.



That's bad.

First, nobody sends an important mail to a new domain without double checking 
its delivery.  It is very reasonable to loose a few test messages when you set 
a new domain up.


By 4xx any unconfigured domain, a warning for delayed email can take hours and 
several attempts.  A 5xx would result in an immediate DSN, which is much better 
in case of mistyping.



Best
Ale
--





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

Re: [mailop] fastmail and sender score snafu

[Jarland Donnell via mailop]

Thanks for the heads up on this. I've just set our mail servers to watch 
out for this and treat it as a 5xx. I hadn't noticed, but if I'd ever 
noticed a 4xx on "Relay access denied" I likely would have added this 
logic immediately without even taking time to second guess it, as I 
can't think of a time that I considered that to be a temporary error 
from anyone.


On 2023-10-07 15:41, Kirill Miazine via mailop wrote:


Hi, mailops

Recently I experienced a very "interesting" case which gave my personal 
email server "poor" "sender score" due to high rate of emails sent from 
my server to non-existent users.


It _couldn't_ be right, as the server is used only by myself and some 
very few family members, and there is no activity which should have 
triggered that score.


I think I figured out what it was. A user sent an email to another 
family member, but using contact's old email domain which used to be 
hosted by Fastmail, but where no such user would exist anymore (I don't 
know if domain still exists as a domain at Fastmail, but clearly MX 
point to them).


I'd guess a 5xx response would be appropriate -- at least on port 25, 
but Fastmail sent 451, and made my Exim try -- and keep re-trying -- 
all IP addresses of all their MX. I have very conservative retry rules, 
so emails would be kept in the queue for a month...


I _guess_ that Fastmail is using sender score, because sender score 
graphs started at the date of that one particular email was sent. So 
every try must have been giving me "bad" score.


And I wouldn't even have discovered that if not OpenSMTPD misc@ lits 
rejected my email, and today would accept it, but add a sender-score 
header, which made me start digging...


Senders to Fastmail beware, and maybe consider treating their 4xx 
errors as permanent.


Logs below:

Oct  7 08:45:03 chroot exim[7614]: 1qlZA1-L8M-1jBn 
H=in1-smtp.messagingengine.com [103.168.172.220]: SMTP error from 
remote mail server after RCPT TO:<...>: 451 4.7.1 <...>: Relay access 
denied


Oct  7 08:45:06 chroot exim[7614]: 1qlZA1-L8M-1jBn 
H=in1-smtp.messagingengine.com [103.168.172.218]: SMTP error from 
remote mail server after RCPT TO:<...>: 451 4.7.1 <...>: Relay access 
denied


Oct  7 08:45:08 chroot exim[7614]: 1qlZA1-L8M-1jBn 
H=in1-smtp.messagingengine.com [103.168.172.216]: SMTP error from 
remote mail server after RCPT TO:<...>: 451 4.7.1 <...>: Relay access 
denied


Oct  7 08:45:10 chroot exim[7614]: 1qlZA1-L8M-1jBn 
H=in1-smtp.messagingengine.com [103.168.172.219]: SMTP error from 
remote mail server after RCPT TO:<...>: 451 4.7.1 <...>: Relay access 
denied


Oct  7 08:45:13 chroot exim[7614]: 1qlZA1-L8M-1jBn 
H=in1-smtp.messagingengine.com [103.168.172.217]: SMTP error from 
remote mail server after RCPT TO:<...>: 451 4.7.1 <...>: Relay access 
denied


Oct  7 08:45:16 chroot exim[7614]: 1qlZA1-L8M-1jBn 
H=in2-smtp.messagingengine.com [64.147.123.52]: SMTP error from remote 
mail server after RCPT TO:<...>: 451 4.7.1 <...>: Relay access denied

___
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] fastmail and sender score snafu

[Benny Pedersen via mailop]

Bill Cole via mailop skrev den 2023-10-09 14:45:

On 2023-10-09 at 03:46:08 UTC-0400 (Mon, 9 Oct 2023 07:46:08 +)
Gellner, Oliver via mailop 
is rumored to have said:

Postfix default of the maximum queue lifetime is 5 days: 
https://www.postfix.org/postconf.5.html#maximal_queue_lifetime
One month is very long, but I usually see systems to retry for at 
least three days to cover outages of MTAs that cannot be solved within 
a few hours or for example happen on a weekend. Not all MTAs are run 
by enterprises with 24/7 staff availability.


5 days has been a widespread norm since the core of the Internet was 
academic and traditional business organizations where you could 
reasonably expect an outage starting on Friday night would not even be 
noticed until Monday morning. I'm pretty sure my first IDA/KJS Sendmail 
machine had a 5-day queue lifetime, as I had no clue how to change 
it...


backup-mx ? :)

should at that time have being 6 to 60 days, more or less, else it would 
not be a backup-mx, but yes sendmail do have most core settings same as 
todays postfix core

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

Re: [mailop] fastmail and sender score snafu

[Bill Cole via mailop]

On 2023-10-09 at 03:46:08 UTC-0400 (Mon, 9 Oct 2023 07:46:08 +)
Gellner, Oliver via mailop 
is rumored to have said:

Postfix default of the maximum queue lifetime is 5 days: 
https://www.postfix.org/postconf.5.html#maximal_queue_lifetime
One month is very long, but I usually see systems to retry for at 
least three days to cover outages of MTAs that cannot be solved within 
a few hours or for example happen on a weekend. Not all MTAs are run 
by enterprises with 24/7 staff availability.


5 days has been a widespread norm since the core of the Internet was 
academic and traditional business organizations where you could 
reasonably expect an outage starting on Friday night would not even be 
noticed until Monday morning. I'm pretty sure my first IDA/KJS Sendmail 
machine had a 5-day queue lifetime, as I had no clue how to change it...


--
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] fastmail and sender score snafu

[Andrew C Aitchison via mailop]

On Mon, 9 Oct 2023, Simon Arlott via mailop wrote:


On 09/10/2023 07:44, Kirill Miazine via mailop wrote:

The reason for a long retry is that I have to manually decrypt mailstore
partition in case of server reboot. Exim would accept the message, but
defer delivery until the mount appears. I wanted to have some time in
case of a reboot and me not being easily available to mount the partition.


You need to configure different retry times for local domains and then
set delay_warning_condition so that it doesn't send warning emails
unless the origin is local.


If Kirill allows forwarding and the forwarding information is stored
on the mailstore, he wont know whether the domain is local or remote
until the mail store comes back on line.

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] fastmail and sender score snafu

[Kirill Miazine via mailop]

I guess discussing my setup (retry rules, queue lifetime or encryption 
setup) is not strictly on the topic, but I'm commenting it further:


• Slavko via mailop [2023-10-09 09:34]:

Dňa 9. 10. o 8:44 Kirill Miazine via mailop napísal(a):

The reason for a long retry is that I have to manually decrypt 
mailstore partition in case of server reboot. Exim would accept the 
message, but defer delivery until the mount appears. I wanted to have 
some time in case of a reboot and me not being easily available to 
mount the partition.


Consider to spend some time to setup auto decrypt on boot, doing that 
manually has little security enhancement on servers, as once decrypted, 
the content is available to OS and thus to potentional attacker too (the 
only restrictions are access rights).


I've come to current setup as good enough approach to protect data in 
"cloud" and remote dedicated server setups, where I didn't want raw data 
on the provider's block storage or physical disk, and where I equally 
didn't want to have another device at the same provider act as a 
decryption key.


And I don't really type in the passphrase normally, a script does that 
over ssh. But when e.g. offline, I have to type it in manually.


When you store decrypt key on separate disk (eg. USB stick), you are 
safe even after disk replace...


For local setups that's an option, for remote setups where provider is 
offering virtual disks it's certainly an option too, but I didn't want 
them to have the key.

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

Re: [mailop] fastmail and sender score snafu

[Kirill Miazine via mailop]

• Simon Arlott via mailop [2023-10-09 09:12]:

On 09/10/2023 07:44, Kirill Miazine via mailop wrote:

The reason for a long retry is that I have to manually decrypt mailstore
partition in case of server reboot. Exim would accept the message, but
defer delivery until the mount appears. I wanted to have some time in
case of a reboot and me not being easily available to mount the partition.


You need to configure different retry times for local domains and then
set delay_warning_condition so that it doesn't send warning emails
unless the origin is local.


I know I could, but current default retry rule has served me so well for 
so many years that I don't add additional logic to deal with theoretical 
edge cases.


However, I am now considering retry rules speecifically for 
in1-smtp.messagingengine.com and in2-smtp.messagingengine.com, and also 
looking at what would be appropriate to as have hosts_max_try and 
hosts_max_try_hardlimit.

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

Re: [mailop] fastmail and sender score snafu

[Gellner, Oliver via mailop]

On 09.10.2023 at 08:24 Robert Mueller via mailop wrote:

>> I see that current setup might be useful in case some user changes MX
>> before the domain is activated at Fastmail, in which case giving 4xx
>> could make sense. But it is not right to report such re-tries to
>> sender score as attempts to deliver to non-existing users.

> Sorry Kirill, I don't have a really good answer right now, though I would say 
> that "emails would be kept in the queue for a month" is probably actively 
> working against you here. There's no reason an email should be queued for 
> that long. 24 hours seems a high upper bound these days and is the postfix 
> default. It's better that it actually bounce sooner to let the sender know 
> that something went wrong rather than trying for a month and the user not 
> knowing that their email is in limbo somewhere.

Postfix default of the maximum queue lifetime is 5 days: 
https://www.postfix.org/postconf.5.html#maximal_queue_lifetime
One month is very long, but I usually see systems to retry for at least three 
days to cover outages of MTAs that cannot be solved within a few hours or for 
example happen on a weekend. Not all MTAs are run by enterprises with 24/7 
staff availability.

--
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] fastmail and sender score snafu

[Slavko via mailop]

Dňa 9. 10. o 8:44 Kirill Miazine via mailop napísal(a):

The reason for a long retry is that I have to manually decrypt mailstore 
partition in case of server reboot. Exim would accept the message, but 
defer delivery until the mount appears. I wanted to have some time in 
case of a reboot and me not being easily available to mount the partition.


Consider to spend some time to setup auto decrypt on boot, doing that 
manually has little security enhancement on servers, as once decrypted, 
the content is available to OS and thus to potentional attacker too (the 
only restrictions are access rights).


When you store decrypt key on separate disk (eg. USB stick), you are 
safe even after disk replace...


regards

--
Slavko

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

Re: [mailop] fastmail and sender score snafu

[Simon Arlott via mailop]

On 09/10/2023 07:44, Kirill Miazine via mailop wrote:
> The reason for a long retry is that I have to manually decrypt mailstore 
> partition in case of server reboot. Exim would accept the message, but 
> defer delivery until the mount appears. I wanted to have some time in 
> case of a reboot and me not being easily available to mount the partition.

You need to configure different retry times for local domains and then
set delay_warning_condition so that it doesn't send warning emails
unless the origin is local.

-- 
Simon Arlott

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

Re: [mailop] fastmail and sender score snafu

[Marco M. via mailop]

Am 09.10.2023 um 17:23:33 Uhr schrieb Robert Mueller:

> It's better that it actually bounce sooner to let the sender know
> that something went wrong rather than trying for a month and the user
> not knowing that their email is in limbo somewhere.

I don't know postfix´s default, but sendmail informs after some hours
if delivery fails, but keeps trying.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] fastmail and sender score snafu

[Kirill Miazine via mailop]

Hi, Rob

Thanks for your email and for confirming my theory.

• Robert Mueller via mailop [2023-10-09 08:23]:



I see that current setup might be useful in case some user changes MX
before the domain is activated at Fastmail, in which case giving 4xx
could make sense. But it is not right to report such re-tries to sender
score as attempts to deliver to non-existing users.


Yes, this is why we 4xx rather than 5xx email sent to an unconfigured domain. 
Many inexperienced email users aren't sure exactly what order to change or set 
things up in and we've seen users lose email before because they changed the MX 
records before adding their domain at Fastmail. The 4xx response reduces the 
chance of lost email.


Exactly what I was thinking, yes.


In general it doesn't really matter that it's 4xx not 5xx. There's no sensible 
reason to point MX records for a domain to us if you're not planning on 
actually using us for your email. If that does happen, the email will 
eventually bounce when the other side gives up trying to resend, which in most 
cases is at most 24 hours.

Now clearly there's an interesting and unexpected edge case that's happened here. The 
logging of repeated delivery to a "non-existent" address has been rolled up 
into a sender score feed that's affected your servers IP reputation, which is really 
annoying.


It is. And if mailing volume would be huge, those retries wouldn't 
matter for the score, but I don't, so, yeah.



Unfortunately fixing the code on this is non-trivial right now since in the 
policy daemon where this logging occurs we don't actually have the information 
we need to suppress this case there and then. I have some longer term ideas for 
this, and will keep this scenario in mind when I get to them.

Sorry Kirill, I don't have a really good answer right now, though I would say that 
"emails would be kept in the queue for a month" is probably actively working 
against you here. There's no reason an email should be queued for that long. 24 hours 
seems a high upper bound these days and is the postfix default. It's better that it 
actually bounce sooner to let the sender know that something went wrong rather than 
trying for a month and the user not knowing that their email is in limbo somewhere.
The reason for a long retry is that I have to manually decrypt mailstore 
partition in case of server reboot. Exim would accept the message, but 
defer delivery until the mount appears. I wanted to have some time in 
case of a reboot and me not being easily available to mount the partition.


I guess I'll have to work with sender score to have them re-set the bad 
score.

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

Re: [mailop] fastmail and sender score snafu

[Robert Mueller via mailop]

> I see that current setup might be useful in case some user changes MX 
> before the domain is activated at Fastmail, in which case giving 4xx 
> could make sense. But it is not right to report such re-tries to sender 
> score as attempts to deliver to non-existing users.

Yes, this is why we 4xx rather than 5xx email sent to an unconfigured domain. 
Many inexperienced email users aren't sure exactly what order to change or set 
things up in and we've seen users lose email before because they changed the MX 
records before adding their domain at Fastmail. The 4xx response reduces the 
chance of lost email.

In general it doesn't really matter that it's 4xx not 5xx. There's no sensible 
reason to point MX records for a domain to us if you're not planning on 
actually using us for your email. If that does happen, the email will 
eventually bounce when the other side gives up trying to resend, which in most 
cases is at most 24 hours.

Now clearly there's an interesting and unexpected edge case that's happened 
here. The logging of repeated delivery to a "non-existent" address has been 
rolled up into a sender score feed that's affected your servers IP reputation, 
which is really annoying.

Unfortunately fixing the code on this is non-trivial right now since in the 
policy daemon where this logging occurs we don't actually have the information 
we need to suppress this case there and then. I have some longer term ideas for 
this, and will keep this scenario in mind when I get to them.

Sorry Kirill, I don't have a really good answer right now, though I would say 
that "emails would be kept in the queue for a month" is probably actively 
working against you here. There's no reason an email should be queued for that 
long. 24 hours seems a high upper bound these days and is the postfix default. 
It's better that it actually bounce sooner to let the sender know that 
something went wrong rather than trying for a month and the user not knowing 
that their email is in limbo somewhere.

-- 
Rob Mueller
r...@fastmail.fm
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] fastmail and sender score snafu

[Marco M. via mailop]

Am 08.10.2023 um 17:58:41 Uhr schrieb Kirill Miazine via mailop:

> • Marco M. via mailop [2023-10-08 14:26]:
> > Am 08.10.2023 um 13:59:10 Uhr schrieb Kirill Miazine:
> >   
> >> Actually the error message "Relay access denied" indicates that
> >> domain is not configured at Fastmail anymore. I just tried and
> >> non-existent users give a different error message:  
> > 
> > Everybody can set an MX to them, so they must reject that as a
> > permanent error. The current way make it look like somebody is
> > trying unauthorized relaying many times.  
> 
> I see that current setup might be useful in case some user changes MX 
> before the domain is activated at Fastmail, in which case giving 4xx 
> could make sense.

I don't see a real reason for that and the disadvantages are there.

MX configuration error shouldn't be handled with such configurations.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] fastmail and sender score snafu

[Kirill Miazine via mailop]

Hi, Tom

Thank you so much for reaching out and for providing an email address to 
get in touch with the sender score operators. I'll email them right away!


-- Kirill

• Tom Bartel via mailop [2023-10-08 18:33]:

Kirill,

I'm with Validity.  I can tell you we are intent on producing quality 
scores and if there is erroneous data feeding the model we are happy to 
take a look at it.  In the case of "bad" input, we'd look at issuing 
corrective measures. You can open a ticket at datahelp at validity dot 
com if you'd like to pursue any further.


Thanks,

Tom

On Sun, Oct 8, 2023 at 10:02 AM Kirill Miazine via mailop 
mailto:mailop@mailop.org>> wrote:



• Marco M. via mailop [2023-10-08 14:26]:
 > Am 08.10.2023 um 13:59:10 Uhr schrieb Kirill Miazine:
 >
 >> Actually the error message "Relay access denied" indicates that
 >> domain is not configured at Fastmail anymore. I just tried and
 >> non-existent users give a different error message:
 >
 > Everybody can set an MX to them, so they must reject that as a
 > permanent error. The current way make it look like somebody is trying
 > unauthorized relaying many times.

I see that current setup might be useful in case some user changes MX
before the domain is activated at Fastmail, in which case giving 4xx
could make sense. But it is not right to report such re-tries to sender
score as attempts to deliver to non-existing users.

I hope Rob & Bron & Co are able to make it right... Now I wonder what
happens with the "sender score" of my mail server, which I've been
operating since early 2000s with tender, love and care.

I find it very unfair that some third party is given an authority to
assign my server some "sender score" based on such false reports. Am I
even able to appeal the score assignment somehow?

 >> 550 5.1.1 : Recipient address rejected: User
 >> unknown in virtual mailbox table
 >
 > That is the right way to deal with that.
 > ___
 > mailop mailing list
 > mailop@mailop.org 
 > https://list.mailop.org/listinfo/mailop

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




--
Phone: 303.517.9655
Website: https://bartelphoto.com 
Instagram: https://instagram.com/bartel_photo 



"Life's most persistent and urgent question is, 'What are you doing for 
others?'" - Martin Luther King Jr.


___
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] fastmail and sender score snafu

[Tom Bartel via mailop]

Kirill,

I'm with Validity.  I can tell you we are intent on producing quality
scores and if there is erroneous data feeding the model we are happy to
take a look at it.  In the case of "bad" input, we'd look at issuing
corrective measures. You can open a ticket at datahelp at validity dot com
if you'd like to pursue any further.

Thanks,

Tom

On Sun, Oct 8, 2023 at 10:02 AM Kirill Miazine via mailop 
wrote:

>
> • Marco M. via mailop [2023-10-08 14:26]:
> > Am 08.10.2023 um 13:59:10 Uhr schrieb Kirill Miazine:
> >
> >> Actually the error message "Relay access denied" indicates that
> >> domain is not configured at Fastmail anymore. I just tried and
> >> non-existent users give a different error message:
> >
> > Everybody can set an MX to them, so they must reject that as a
> > permanent error. The current way make it look like somebody is trying
> > unauthorized relaying many times.
>
> I see that current setup might be useful in case some user changes MX
> before the domain is activated at Fastmail, in which case giving 4xx
> could make sense. But it is not right to report such re-tries to sender
> score as attempts to deliver to non-existing users.
>
> I hope Rob & Bron & Co are able to make it right... Now I wonder what
> happens with the "sender score" of my mail server, which I've been
> operating since early 2000s with tender, love and care.
>
> I find it very unfair that some third party is given an authority to
> assign my server some "sender score" based on such false reports. Am I
> even able to appeal the score assignment somehow?
>
> >> 550 5.1.1 : Recipient address rejected: User
> >> unknown in virtual mailbox table
> >
> > That is the right way to deal with that.
> > ___
> > mailop mailing list
> > mailop@mailop.org
> > https://list.mailop.org/listinfo/mailop
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>


-- 
Phone: 303.517.9655
Website: https://bartelphoto.com
Instagram: https://instagram.com/bartel_photo

"Life's most persistent and urgent question is, 'What are you doing for
others?'" - Martin Luther King Jr.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] fastmail and sender score snafu

[Kirill Miazine via mailop]

• Marco M. via mailop [2023-10-08 14:26]:

Am 08.10.2023 um 13:59:10 Uhr schrieb Kirill Miazine:


Actually the error message "Relay access denied" indicates that
domain is not configured at Fastmail anymore. I just tried and
non-existent users give a different error message:


Everybody can set an MX to them, so they must reject that as a
permanent error. The current way make it look like somebody is trying
unauthorized relaying many times.


I see that current setup might be useful in case some user changes MX 
before the domain is activated at Fastmail, in which case giving 4xx 
could make sense. But it is not right to report such re-tries to sender 
score as attempts to deliver to non-existing users.


I hope Rob & Bron & Co are able to make it right... Now I wonder what 
happens with the "sender score" of my mail server, which I've been 
operating since early 2000s with tender, love and care.


I find it very unfair that some third party is given an authority to 
assign my server some "sender score" based on such false reports. Am I 
even able to appeal the score assignment somehow?



550 5.1.1 : Recipient address rejected: User
unknown in virtual mailbox table


That is the right way to deal with that.
___
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] fastmail and sender score snafu

[Marco M. via mailop]

Am 08.10.2023 um 12:36:58 Uhr schrieb Slavko via mailop:

> Except that who know what "virtual mailbox table" means...

That is a virtusertable for mapping aliases with a domain format at the
LHS (left hand side) instead of just the user part that matches all
local domains in /etc/mail/aliases.

For example with sendmail it is /etc/mail/virtusertable.

john@example.orgjohn
ab...@example.orgmeyer
postmas...@example.org  meyer
@example.org error:5.1.1:550 No such mailbox

Postfix also supports that, IIRC it is named valiases.

Often the users with their domain part are listed there and mapped to a
user name or rejected like in the example.

Goal:
Make j...@example.org and j...@test.example.org behaving different
while both domains are considered local (class w in sendmail).
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] fastmail and sender score snafu

[Slavko via mailop]

Dňa 8. októbra 2023 12:26:41 UTC používateľ "Marco M. via mailop" 
 napísal:

>> 550 5.1.1 : Recipient address rejected: User
>> unknown in virtual mailbox table
>
>That is the right way to deal with that.

Except that who know what "virtual mailbox table" means...

regards


-- 
Slavko
https://www.slavino.sk/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] fastmail and sender score snafu

[Marco M. via mailop]

Am 08.10.2023 um 13:59:10 Uhr schrieb Kirill Miazine:

> Actually the error message "Relay access denied" indicates that
> domain is not configured at Fastmail anymore. I just tried and
> non-existent users give a different error message:

Everybody can set an MX to them, so they must reject that as a
permanent error. The current way make it look like somebody is trying
unauthorized relaying many times.

> 550 5.1.1 : Recipient address rejected: User
> unknown in virtual mailbox table

That is the right way to deal with that.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] fastmail and sender score snafu

[Kirill Miazine via mailop]

Rob (BCC), Bron (BCC), will you please make someone have a look at it? 
The problem is that Fastmail MX respond with 4xx to addresses at domains 
which are not configured at Fastmail AND reports each of those temporary 
rejections as an attempt of delivery to non-existing user. This has made 
my own tiny server get bad "sender score"... Now I don't know how much 
sender score is really used and whether it will be reset at some point.


• Marco M. via mailop [2023-10-08 08:55]:

Am 07.10.2023 um 22:41:01 Uhr schrieb Kirill Miazine via mailop:


Recently I experienced a very "interesting" case which gave my
personal email server "poor" "sender score" due to high rate of
emails sent from my server to non-existent users.


Normal, because spammers often have mass of non-existing (mostly not
anymore) addresses and because these lists are often sold, many
spammers will try it.


I think I figured out what it was. A user sent an email to another
family member, but using contact's old email domain which used to be
hosted by Fastmail, but where no such user would exist anymore (I
don't know if domain still exists as a domain at Fastmail, but
clearly MX point to them).


Actually the error message "Relay access denied" indicates that domain 
is not configured at Fastmail anymore. I just tried and non-existent 
users give a different error message:


550 5.1.1 : Recipient address rejected: User unknown 
in virtual mailbox table



I'd guess a 5xx response would be appropriate -- at least on port 25,
but Fastmail sent 451, and made my Exim try -- and keep re-trying --
all IP addresses of all their MX. I have very conservative retry
rules, so emails would be kept in the queue for a month...


That is fastmails bad configuration. Permanent errors like "mailbox
doesn't exist" must have a permanent error code (5xx) to avoid retry.


Senders to Fastmail beware, and maybe consider treating their 4xx
errors as permanent.


Fastmail must fix that - every MTA will try it again and again if a 4xx
error occurs and that will flood them with the messages many times.


And senders given bad sender score eventually, and especially low-volume 
servers.

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

Re: [mailop] fastmail and sender score snafu

[Marco M. via mailop]

Am 07.10.2023 um 22:41:01 Uhr schrieb Kirill Miazine via mailop:

> Recently I experienced a very "interesting" case which gave my
> personal email server "poor" "sender score" due to high rate of
> emails sent from my server to non-existent users.

Normal, because spammers often have mass of non-existing (mostly not
anymore) addresses and because these lists are often sold, many
spammers will try it.

> I think I figured out what it was. A user sent an email to another 
> family member, but using contact's old email domain which used to be 
> hosted by Fastmail, but where no such user would exist anymore (I
> don't know if domain still exists as a domain at Fastmail, but
> clearly MX point to them).

> I'd guess a 5xx response would be appropriate -- at least on port 25, 
> but Fastmail sent 451, and made my Exim try -- and keep re-trying --
> all IP addresses of all their MX. I have very conservative retry
> rules, so emails would be kept in the queue for a month...

That is fastmails bad configuration. Permanent errors like "mailbox
doesn't exist" must have a permanent error code (5xx) to avoid retry.

> Senders to Fastmail beware, and maybe consider treating their 4xx
> errors as permanent.

Fastmail must fix that - every MTA will try it again and again if a 4xx
error occurs and that will flood them with the messages many times.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop