Mail to pve-devel blocked

[mir]

Hi all,
When I try to send email to the pve-devel list by mail is returned with the following response:

<pve-devel@lists.proxmox.com>: host firstgate.proxmox.com[212.224.123.68] said:
550 5.7.1 Service unavailable; client [83.93.223.153] blocked using
zen.spamhaus.org (in reply to RCPT TO command)

Looking up this up at smaphaus.org tells:
Outbound Email Policy of The Spamhaus Project for this IP range:

This IP address range has been identified by Spamhaus as not meeting our policy for IP addresses permitted to deliver unauthenticated 'direct-to-mx' email to PBL users.
Important: If you are using any normal email software (such as Outlook, Entourage, Thunderbird, Apple Mail, etc.) and you are being blocked by this Spamhaus PBL listing when you try to send email, the reason is simply that you need to turn on "SMTP Authentication" in your email program settings. For help with SMTP Authentication or ways to quickly fix this problem click here.

Above is incorrect and would also be impossible to detect. How can a list server identify whether a mail was send through a mail server using authentication or not?

 

[Stoiko Ivanov]

I suppose the IP is in a block that looks like it's being used for residential access, guessing from whois information - thus it's listed by spamhaus

The explanation they offer on their page will not work in all situations (like this one) - but quite often it will help users see that the issue is not using SMTP-AUTH when talking to their provider's mailserver

In this case the explanation is misleading though.

Could you maybe relay the mail via some other system you have access to?

I hope this helps!

 

[mir]

I suppose the IP is in a block that looks like it's being used for residential access, guessing from whois information - thus it's listed by spamhaus

The explanation they offer on their page will not work in all situations (like this one) - but quite often it will help users see that the issue is not using SMTP-AUTH when talking to their provider's mailserver

In this case the explanation is misleading though.

Could you maybe relay the mail via some other system you have access to?

I hope this helps!

For privacy reasons I use my own email server. Also relaying through another email server pose some difficulties on me since it will be difficult to register a mail address to the pve-devel list not matching the the email servers domain ;-)

 

[mir]

But now it is you Stoiko who is responding. I was actually trying to ask you a question on the pve-devel list:
On Mon, 12 Oct 2020 17:34:56 +0200

Stoiko Ivanov <s.ivanov@proxmox.com> wrote:

> This patchset follows the fix in
> 609f117ff24d2cff6b155e1d4b1175ceebe5bd7b. Since several operations
> rely on values read from the remote target's LIO config (which is
> tainted), this patchset untaints the settings, which are actually
> needed (and stores only those), while reading the config.
>
Is this only needed for PVE/Storage/LunCmd/LIO.pm or should additional
actions be taken for other LunCmd backends as well?

 

[Stoiko Ivanov]

Is this only needed for PVE/Storage/LunCmd/LIO.pm or should additional
actions be taken for other LunCmd backends as well?

from a quick glance at the code the other LunCmd backends parse line-based configs and while doing that untaint the values they save.

so I would not expect them to run into the same issue (the problem with the LIO backend was due to it reading a JSON config and then using it as perl-object)

I hope this explains it!

 

[mir]

from a quick glance at the code the other LunCmd backends parse line-based configs and while doing that untaint the values they save.

so I would not expect them to run into the same issue (the problem with the LIO backend was due to it reading a JSON config and then using it as perl-object)

I hope this explains it!

Sounds reasonable. Thanks.