Just something to take note of.
A bunch of my sites all of a sudden stopped being able to send mail to certain locations.
Usually in a case like that it is because of being listed on a blacklist somewhere or invalid configuration.
I checked the RBL lists and they were all clean.
I verified my setup and MXtoolbox.com and my PTR records were in place.
In conjunction with the ISP of one of the sites refusing my mail, I found out that I have been SBRS'ed (Senderbase Reputation Service)
Senderbase uses a bunch of different rules and rate your mail server. My rating dropped because of a simple rating method they use called badehlo.
To explain this to non technical users - this is the greetings mail servers exchange before sending messages.
Now RFC 5321 cf. Sections 2.3.4, 4.1.1.1, 4.1.3 requires clients to use the Fully Qualified Domain Name as the HELO string during the SMTP conversation, but SME (or more correctly the SMTP service only uses the domain name).
So your server greets the other server as domain.com instead of the prescribed mailserver.domain.com
There is a lot of contention and varying opinions on whether a bad ehlo is a valid spam fighting tool, but that does not solve the problem, as the ISP's are very arrogant and not very interested on whitelisting you. Meanwhile you have to suffer for 3 - 4 days while your reputation is being re-evaluated.
SBRS also does not allow you to de-list after fixing a problem - their view is you have to wait for your reputation to improve again.
Of course - living in a materialistic world - you can buy their device and pay buckets full of money to have a good rating
.
The fix is quite simple - if your reputation is still good. (Copied from an existing post here)
FIX[root@srvsrv ~]# cat /var/qmail/control/helohost
solinf.org
[root@srvsrv ~]# config setprop smtpd HeloHost pippo.solinf.org
[root@srvsrv ~]# signal-event email-update
[root@srvsrv ~]# cat /var/qmail/control/helohost
pippo.solinf.org
REMOVING THE FIX[root@srvsrv ~]# config delprop smtpd HeloHost
[root@srvsrv ~]# signal-event email-update
[root@srvsrv ~]# cat /var/qmail/control/helohost
solinf.org
Now - the question I pose is as follows
The long term (or pre-emptive) fix seem to be quite a simple one as this HeloHost is defined in the templates /etc/e-smith/templates/var/qmail/control/helohost and contains the following
{ $smtpd{HeloHost} || $DomainName }whereas it might contain something like
{ $smtpd{HeloHost} || $SystemName.$DomainName }Now I am not sure the above is correct, or if it will work, but can the devs ( I know they are overworked and under appreciated ) not make this fix permanent. If I knew how to without breaking it during the next update - I would have tried.
Tied in with that is another simple thing.
I will explain my predicament
I have 2 sites (as an example)
Users between the 2 sites and visitors are very dynamic. In other words I can never predict who is going to be at which site.
So to simplify things - I turned off SMTP proxy and allow the guys to use their own SMTP server when sending mails from any of these sites.
The SME's are set up to allow SMTP Auth on the external interfaces.
All is rose colored in the world of IT.
Except
Every now and again - an external user rocks up, and is infected with some bug. Distributes SPAM. And voila - I have to clean queues and request delisting from a lot of blacklists.
I know the standard answer (I do search before posting) is to enable smtp auth on the internal network to prevent the infected machines from spreading SPAM.
This however creates a whole new problem - because if I have a guest or a user from a different site - they cannot authenticate as they have no username on the system. I get call upon call that the guys are prompted for network passwords (Which they obviously do not have) If you have 15 sites with a traveling salesman visiting each of those - it becomes a nightmare in admin.
So there are a couple of solutions out there
1) Enable all mails to be checked for SPAM as follows:
mkdir -p /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/local
ln -s /etc/e-smith/templates/var/service/qpsmtpd/config/plugins/70spamassassin /etc/e-smith/templates-custom/var/service/qpsmtpd/config/peers/local/70spamassassin
expand-template /var/service/qpsmtpd/config/peers/local
signal-event email-update
2) Force all users to work with a VPN
Solution 1 seems like a reasonable choice - for smaller sites that have good enough hardware, but even with a monster server your mail will go down if it gets hit with 20 000 spams per hour from a host
Solution 2 is also a reasonable choice - but also creates a problem if you have VPN issues.
Now - please do not get me wrong - I love SME and the work they are doing and nothing would make me happier than to see this as a de facto standard for small to medium enterprises.
However - I feel if we had a panel (where generation X - The guys that cannot use a PC if they do not hold on to a mouse) to do the above - I think we would make a move in the right direction.
Alternatively - if we had some standard controls (also with a panel) that limits the amount of mail a user can send per hour for instance - Ecstacy.
This is not a bashing of SME or what it is capable of, rather an open discussion to see if I am alone in my thinking, or if some others share my thinking, or even better - if there is something basic I missed in the manual that will make all my troubles disappear.
Awaiting your feedback with much anticipation.
5 Replies
6691 Views