I was thinking more in terms of Proxmox recognizing that it had already added a disclaimer in a previous message or reply and NOT adding another. No deletion of text required -- simply not appending more.
I have seen such features advertised for other mail products.
The message was never stored at any point, so I can not provide a copy at this time. It's not happening all that often, so I'm not sure when I'll see another example.
We have a couple of addresses that get forwarded (by our back-end mail system) to addresses outside of our domain. We occasionally get notifications from proxmox that it blocked an outbound virus going to that forwarded external address. So it appears that the message gets past the inbound virus...
I was looking at the headers in a message sent from our domain to the outside world and noticed that all the host names and private IP addresses of all the internal systems through which the message passed were visible.
A quick search yielded this...
We replaced our file server with Win 2008 x64. Now proxmox scheduled backups are failing. Windows share permissions are the same. Just changed the hostname in the proxmox backup configuration. From other Windows machines, I can read/write on the share using the same account that I am providing...
Not Exchange: Linux
No MS Exchange here. Linux postfix/cyrus-imapd on the back-end.
We have built-in linux aliases in /etc/aliases as well as some distribution lists stored in AD that we do NOT want to be deliverable from outside sources.
In postfix we have:
alias_maps = hash:/etc/aliases...
Our implementation of recipient verification is working nicely with one exception. Certain mail aliases are intended for internal use only, yet they successfully pass receiver verification because they are deliverable on the back-end mail servers. So we created a Who list and a Block/Notify...
One last (I hope) question about recipient verification...
It appears that rejects due to failed recipient verification are not counted anywhere in the statistics. Is that correct?
I understand that no mail content is transmitted when a recipient verification fails, but the process still...
Here for one...
http://www.proxmox.com/forum/showpost.php?p=1100&postcount=6
It's hard to tell right away, but it appears to have made a difference. Looking at the greylist logs, I can see that timestamps before I made the change only had valid recipients. After the change, the greylist log...
From reading the forums, I understand that receiver verification comes before greylisting, but I don't understand the reason for this choice.
We used to maintain lists of valid addresses in Proxmox and block all others instead of using receiver verification. This limited virtually all...
We use greylisting, so our users have come to learn that sometimes it's best to whitelist a new contact to avoid the first-time delays. However, as administrators, we are growing somewhat tired of manually adding whitelist entries on behalf of our users.
The web interface link in the daily spam...
We have recently been getting complaints from internal users that legitimate messages to them from outside are being rejected. When we search the proxmox logs, we often find it's an SPF issue on the sender's side.
I like the idea of SPF and if people are going to configure their domain for it...
Not a big deal, but I'm wondering why this is happening. Some,
but not all, daily spam reports are coming through with some
character set information embedded in the subject. See
header excerpt below.
Any ideas why?
Content-Type: multipart/related...
We recently reconfigured our network to pipe all outgoing messages through proxmox. The daily status report tells me how many outgoing mails bounced, but nothing else. I had become accustomed to receiving a handful of bounce messages directed to postmaster@mydomain.com, but now I get nothing...
I know this is an old thread, but I just wanted to add my 2 cents...
The sender address for notifications really should be configurable by Proxmox users. Why on earth would we want to expose our internal hostnames on public DNS? Bad, bad, bad.... That's why we all use a CNAME mail.domain.tld...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.