Send users mailing list submissions to
users@exim4u.org
To subscribe or unsubscribe via the World Wide Web, visit
https://exim4u.org/mailman/listinfo/users
or, via email, send a message with subject or body 'help' to
users-request@exim4u.org
You can reach the person managing the list at
users-owner@exim4u.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of users digest..."
Today's Topics:
1. Blacklisted URL in message (Terry)
2. Re: Blacklisted URL in message (Gordon Dickens)
3. Re: Blacklisted URL in message (Terry)
4. Re: Blacklisted URL in message (Gordon Dickens)
5. Re: Blacklisted URL in message (Terry)
6. Re: Blacklisted URL in message (Gordon Dickens)
7. Fix suggestion for broken login on Linux Distributions with
suhosin patched PHP (e.G. Debian Wheezy) (Seidel, Michael)
8. exim 4.84 (Valkanover Harald)
----------------------------------------------------------------------
Message: 1
Date: Thu, 19 Jun 2014 12:08:23 +0100
From: Terry <terry@firstkmh.co.uk>
To: users@exim4u.org
Subject: [Exim4U] Blacklisted URL in message
Message-ID: <53A2C4A7.1070600@firstkmh.co.uk>
Content-Type: text/plain; charset=ISO-8859-1
Hi one of our customers complained about not receiving some email and it
seems they were blocked due to black listed url but I went and checked
and they are not listed. Unless they recently became unlisted ?
+++ 1WxHw9-000PUG-3y has not completed +++
2014-06-18 15:38:09 1WxHw9-000PUG-3y H=mail50.scotnet.co.uk
(sys30.scotnet.net) [217.16.223.65] F=<sjones@pesol.co.uk> rejected
during MIME ACL checks: Blacklisted URL in message.
(pritchard-edwards.co.uk) in. See http://lookup.uribl.com.
+++ 1Wwpio-000MvZ-TN has not completed +++
2014-06-17 09:30:31 1Wwpio-000MvZ-TN H=smtp.clearstreamgroup.co.uk
(smtp2.clearstreamtechnology.co.uk) [46.17.208.145]
F=<rhys.taylor@30parkplace.co.uk> rejected during MIME ACL checks:
Blacklisted URL in message. (familyarbitrator.com) in. See
http://lookup.uribl.com.
--
------------------------------------
Terry
------------------------------
Message: 2
Date: Thu, 19 Jun 2014 08:01:41 -0400
From: Gordon Dickens <gecko@exim4u.org>
To: Exim4U General Discussion <users@exim4u.org>
Subject: Re: [Exim4U] Blacklisted URL in message
Message-ID: <53A2D125.6070201@exim4u.org>
Content-Type: text/plain; charset="us-ascii"
An HTML attachment was scrubbed...
URL: <http://exim4u.org/pipermail/users/attachments/20140619/d09f4d1c/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 20 Jun 2014 09:41:01 +0100
From: Terry <terry@firstkmh.co.uk>
To: users@exim4u.org
Subject: Re: [Exim4U] Blacklisted URL in message
Message-ID: <53A3F39D.7020409@firstkmh.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
They have had there own email blocked yesterday as well when trying to
email from a home address.
But when I check the logs it seems to be catching legitimate emails as
well as it should.
I didn't want to disable it as it does a good job but may have to.
--
------------------------------------
Terry
------------------------------
Message: 4
Date: Fri, 20 Jun 2014 08:54:23 -0400
From: Gordon Dickens <gecko@exim4u.org>
To: Exim4U General Discussion <users@exim4u.org>
Subject: Re: [Exim4U] Blacklisted URL in message
Message-ID: <53A42EFF.2030105@exim4u.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Exim4U does not do a URIBL check for authenticated mail. So, assuming
that they use authentication for local mail, something very weird is
going on for their own mail to be blocked. That should not be
possible. Otherwise, their exim4u configuration must have somehow
gotten mangled.
It sounds like they may be having a DNS problem with the URIBL lookups.
Do they use their own caching DNS server or are they using a public DNS
server? I strongly recommend that they use their own DNS server with
bind/named. Otherwise, the use of public DNS servers can cause
unpredictable results such as refused queries and false positive
results. Note that URIBL may refuse queries from any high volume DNS
server. So, if they are using a public DNS server then I recommend that
they setup their own caching name server with bind/named.
FYI,
Gordon
On 06/20/2014 04:41 AM, Terry wrote:
> They have had there own email blocked yesterday as well when trying to
> email from a home address.
> But when I check the logs it seems to be catching legitimate emails as
> well as it should.
> I didn't want to disable it as it does a good job but may have to.
>
>
>
>
>
>
>
>
------------------------------
Message: 5
Date: Tue, 24 Jun 2014 14:12:58 +0100
From: Terry <terry@firstkmh.co.uk>
To: users@exim4u.org
Subject: Re: [Exim4U] Blacklisted URL in message
Message-ID: <53A9795A.6000509@firstkmh.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi by there own address I meant a gmail one so they noticed the block.
They do have there own caching dns server and every thing seems in order.
I have disabled the check for them so things are fine now. But it was a
bit puzzling
--
------------------------------------
Terry
------------------------------
Message: 6
Date: Thu, 26 Jun 2014 08:55:44 -0400
From: Gordon Dickens <gecko@exim4u.org>
To: Exim4U General Discussion <users@exim4u.org>
Subject: Re: [Exim4U] Blacklisted URL in message
Message-ID: <53AC1850.4010305@exim4u.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi Terry,
I thought of another thing to look at. The uribl lookups are done in a
script that is included in the Exim4U installation here:
/etc/exim/exim.pl/exim_surbl.pl
This script checks three URL blacklists: SURBL, URIBL and DBL. The exim
log entries that you sent in your first email were all only URIBL
lookups. So, you may consider re-enabling the lookups in
/etc/exim/exim.conf and disabling only the URIBL blacklist directly in
/etc/exim/exim.pl/exim_surbl.pl to determine if the problem is only with
the URIBL blacklist or with all three blacklists.
Look at lines 61 through 65 in exim_surbl.pl:
# The following ariables enable or disable the SURBL, URIBL and DBL
# lookups. Set to 1 to enable and 0 to disable.
my $surbl_enable = 1;
my $uribl_enable = 1;
my $dbl_enable = 1;
Here, you can disable/enable each blacklist individually. If, for some
reason, you find that the problem only exists with the URIBL blacklist
then you can keep the script running and benefit from the other two
blacklists.
This script was written by Erik Mugele and you can read more about it here:
http://www.teuton.org/~ejm/exim_surbl/
If you find that all three lists generate false positives, then I would
suggest that the problem probably is directly related to this
installation's DNS lookups. Whereas, if the problem only occurs with
the URIBL then I'm not sure what to say. In any event, Erik Mugele's
script is well known and popular within the exim community and this is
the first time that I have ever heard of this type of problem that was
not caused by the use of a public or large ISP's DNS servers. So, if
you make any progress diagnosing this problem please let me know what
you find.
Thanks,
Gordon
On 06/24/2014 09:12 AM, Terry wrote:
> Hi by there own address I meant a gmail one so they noticed the block.
> They do have there own caching dns server and every thing seems in order.
> I have disabled the check for them so things are fine now. But it was
> a bit puzzling
>
------------------------------
Message: 7
Date: Tue, 5 Aug 2014 07:09:13 +0000
From: "Seidel, Michael" <michael.seidel@fai.ag>
To: "'users@exim4u.org'" <users@exim4u.org>
Subject: [Exim4U] Fix suggestion for broken login on Linux
Distributions with suhosin patched PHP (e.G. Debian Wheezy)
Message-ID:
<FE5645E4AC03CE42B529FA5B277580590178A5FC9F@FAI-EX01.fai.ag>
Content-Type: text/plain; charset="us-ascii"
Hi List,
I ran into a problem lately and I thought it was best to report my findings. I was upgrading a system Debian Lenny to Wheezy (yeah, I know, it took some time, but it was for internal use anyway) and therefor from vexim to exim4u.
So far so good, but after changing the password from CHANGE to something else failed my login. A quick look in the database revealed the issue:
The password encryption scheme changed from md5 to sha512, as you can easily see on the encrypted passwords itself:
Old: CHANGE : $1$12345678$2lQK5REWxaFyGz.p/dos3/
New: CHANGE : $6$P0s1h8hgqT/K$qGoe/zSh6crG/MsDTlnxmnGGufEVftsB2sPCgfopV6TmoT2XBVgGQ6cAu00GJUY9GHaTO1RsNDJUNwY1MZqQa/
See http://php.net/manual/en/function.crypt.php for those without crypto basic knowledge with additional information on this.
The old one was plain MD5 (starting with $1$SALT$...), which you should not use anymore, but better than plain, right guys? ;-))) A real patch for this incoming? I'll be looking at http://axel.sjostedt.no/misc/dev/vexim-customizations/ next.
The new one is SHA-512 (Starting with $6$SALT$...), which is way longer (so it needed the - already implemented - var(255) mysql patch mentioned on this list before) and it has a 16 character salt.
But login was broken at that point. I found out, that a suhosin patch was added to Debian PHP - to promote more secure passwords, but it broke some older scripts.
After some fiddling with the function crypt_password code in ./config/functions.php I'd suggest a code change to:
---------------------------
function crypt_password($clear, $salt = '')
{
global $cryptscheme;
if ($cryptscheme == 'sha')
{
$hash = sha1($clear);
$cryptedpass = '{SHA}' . base64_encode(pack('H*', $hash));
}
else
{
if ($salt != '')
{
if ($cryptscheme == 'sha512')
{
$salt = substr($salt, 0, 16);
}
else
if ($cryptscheme == 'des')
{
$salt = substr($salt, 0, 2);
}
else
if ($cryptscheme == 'md5')
{
$salt = substr($salt, 0, 12);
}
else
{
$salt = '';
}
$cryptedpass = crypt($clear, $salt);
}
else {
$cryptedpass = crypt($clear);
}
}
return $cryptedpass;
}
---------------------------
So if somebody ran into that problem again they just have to set
/* Set to either "sha", "sha512", "des" or "md5" depending on your crypt() libraries */
$cryptscheme = "sha512";
in
./config/variables.php
---------------------------
Some real class to check which encoding to use would be more cool but not necessary IMHO. You need to configure your backend with certain encoding anyways, just think about IMAP/POP services which require a set crypt scheme.
BUG: My code piece will result in first login failures if somebody just did not login first to have the password converted from md5 to sha-512 to find out their system changed their encoding but already changed the var in variables.php to sha512.
They eventually come here to read about this: So please change it back to default: md5 , login and than change it back to sha512 or copy that sha512 crypt password from above to database.
So what does the List say about this? Is this the correct solution?
Regards,
Michael Seidel
System Administrator
FAI rent-a-jet AG
http://www.fai.ag
------------------------------
Message: 8
Date: Tue, 2 Sep 2014 09:22:12 +0200
From: "Valkanover Harald" <valki@valki.com>
To: <users@exim4u.org>
Subject: [Exim4U] exim 4.84
Message-ID: <000001cfc67e$9db8d9f0$d92a8dd0$@valki.com>
Content-Type: text/plain; charset="us-ascii"
Hi list!
Is anyone sucessfully running exim4u with exim 4.84? I made an update to
that exim version and had to find out that several transports were broken
(around remove_header, failed to expand with some sql statements etc.).
I made some customizations but it looks like a general compatibility problem
- can anyone confirm?
Kind regards,
Valki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://exim4u.org/pipermail/users/attachments/20140902/46526caa/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
users mailing list
users@exim4u.org
https://exim4u.org/mailman/listinfo/users
------------------------------
End of users Digest, Vol 35, Issue 1
************************************