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
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 attemp
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
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 m
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 re
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 want
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 decr
• 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
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 t
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
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
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 info
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 repor
> 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
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 ju
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
sco
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 y
• 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
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.
Fo
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
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 a
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 ow
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-e
23 matches
Mail list logo
