headers
Jake Vickers | 25 Feb 04:06
Favicon

[qmailtoaster-devel] qmail-toaster test package with chkuser 2.0.9

I've rolled a new version of QMT that has chkuser 2.0.9 and some new 
changes rolled into it. Here is the link:
http://qmailtoaster.com/testing/qmail-toaster-1.03-1.3.21.src.rpm

The first change is that it should no longer check for the remote MX 
record and error out for this. It will be passed back to the MTA to 
reject and deliver a NDR to the end user.

Next is the addition of the "illegal" characters. Specifically, these 
are now allowed:

#define CHKUSER_ALLOW_SENDER_CHAR_1 '$'
#define CHKUSER_ALLOW_SENDER_CHAR_2 '%'
#define CHKUSER_ALLOW_SENDER_CHAR_3 '/'
#define CHKUSER_ALLOW_SENDER_CHAR_4 '?'
#define CHKUSER_ALLOW_SENDER_CHAR_5 '*'
#define CHKUSER_ALLOW_SENDER_CHAR_6 '^'
#define CHKUSER_ALLOW_SENDER_CHAR_7 '~'
#define CHKUSER_ALLOW_SENDER_CHAR_8 '&'
#define CHKUSER_ALLOW_SENDER_CHAR_9 '#'
#define CHKUSER_ALLOW_SENDER_CHAR_10 '='

Unfortunately, I have no way of checking some of these characters since 
they throw a monkey wrench into my dir structure.
Anyway, if some would like to download the package a do some testing, it 
would be appreciated.
Thanks.
Permalink | Reply |
headers
Amit | 25 Feb 05:47
Picon

RE: [qmailtoaster-devel] qmail-toaster test package with chkuser 2.0.9

I just upgraded to chkuser 2.0.9 manually from their website yesterday and
till now its working fine. Will give it a try on another server.

Amit Dalia

     
-----Original Message-----
From: Jake Vickers [mailto:jake <at> qmailtoaster.com] 
Sent: Friday, February 25, 2011 8:36 AM
To: qmailtoaster-devel <at> qmailtoaster.com
Subject: [qmailtoaster-devel] qmail-toaster test package with chkuser 2.0.9

I've rolled a new version of QMT that has chkuser 2.0.9 and some new 
changes rolled into it. Here is the link:
http://qmailtoaster.com/testing/qmail-toaster-1.03-1.3.21.src.rpm

The first change is that it should no longer check for the remote MX 
record and error out for this. It will be passed back to the MTA to 
reject and deliver a NDR to the end user.

Next is the addition of the "illegal" characters. Specifically, these 
are now allowed:

#define CHKUSER_ALLOW_SENDER_CHAR_1 '$'
#define CHKUSER_ALLOW_SENDER_CHAR_2 '%'
#define CHKUSER_ALLOW_SENDER_CHAR_3 '/'
#define CHKUSER_ALLOW_SENDER_CHAR_4 '?'
#define CHKUSER_ALLOW_SENDER_CHAR_5 '*'
#define CHKUSER_ALLOW_SENDER_CHAR_6 '^'
#define CHKUSER_ALLOW_SENDER_CHAR_7 '~'
(Continue reading)

Permalink | Reply |
headers
Eric Shubert | 25 Feb 15:21
Favicon

Re: [qmailtoaster-devel] qmail-toaster test package with chkuser 2.0.9

On 02/24/2011 08:06 PM, Jake Vickers wrote:
>
> The first change is that it should no longer check for the remote MX
> record and error out for this. It will be passed back to the MTA to
> reject and deliver a NDR to the end user.

I've been pestered by this one in the past, so I'm glad to see an 
improvement in this area. I'm not clear about the change though.

It seems to me that the requirements for this differ between inbound and 
outbound messages. For incoming inter-domain mail, if it doesn't error 
out for a missing sender's MX record, how is it going to pass it back? I 
don't think I understand what Jake is saying here. (But I've had no 
coffee yet today, so that might be the problem).

I see that spamdyke has this check as well (reject-missing-sender-mx). I 
think it'd be good to let spamdyke handle this check, so it could be 
overridden by a whitelist entry when appropriate. This would take care 
of the cases which have pestered me in the past.

However, this means that the check would not be done for authenticated 
sessions, nor submissions, allowing messages with a malformed return 
address (at least the domain part) to be sent out. I'm not so sure this 
is a good thing, as bounces would fail and messages would "vaporize".

What am I missing?

--

-- 
-Eric 'shubes'
(Continue reading)

Permalink | Reply |
headers
Jake Vickers | 25 Feb 16:28
Favicon

Re: [qmailtoaster-devel] qmail-toaster test package with chkuser 2.0.9

On 02/25/2011 09:21 AM, Eric Shubert wrote:
> On 02/24/2011 08:06 PM, Jake Vickers wrote:
>>
>> The first change is that it should no longer check for the remote MX
>> record and error out for this. It will be passed back to the MTA to
>> reject and deliver a NDR to the end user.
>
> I've been pestered by this one in the past, so I'm glad to see an 
> improvement in this area. I'm not clear about the change though.
>
> It seems to me that the requirements for this differ between inbound 
> and outbound messages. For incoming inter-domain mail, if it doesn't 
> error out for a missing sender's MX record, how is it going to pass it 
> back? I don't think I understand what Jake is saying here. (But I've 
> had no coffee yet today, so that might be the problem).
>
> I see that spamdyke has this check as well (reject-missing-sender-mx). 
> I think it'd be good to let spamdyke handle this check, so it could be 
> overridden by a whitelist entry when appropriate. This would take care 
> of the cases which have pestered me in the past.
>
> However, this means that the check would not be done for authenticated 
> sessions, nor submissions, allowing messages with a malformed return 
> address (at least the domain part) to be sent out. I'm not so sure 
> this is a good thing, as bounces would fail and messages would 
> "vaporize".
>
> What am I missing?
>
(Continue reading)

Permalink | Reply |
headers
Eric Shubert | 15 May 17:55
Favicon

Re: [qmailtoaster-devel] qmail-toaster test package with chkuser 2.0.9

On 02/25/2011 08:28 AM, Jake Vickers wrote:
> On 02/25/2011 09:21 AM, Eric Shubert wrote:
>> On 02/24/2011 08:06 PM, Jake Vickers wrote:
>>>
>>> The first change is that it should no longer check for the remote MX
>>> record and error out for this. It will be passed back to the MTA to
>>> reject and deliver a NDR to the end user.
>>
>> I've been pestered by this one in the past, so I'm glad to see an
>> improvement in this area. I'm not clear about the change though.
>>
>> It seems to me that the requirements for this differ between inbound
>> and outbound messages. For incoming inter-domain mail, if it doesn't
>> error out for a missing sender's MX record, how is it going to pass it
>> back? I don't think I understand what Jake is saying here. (But I've
>> had no coffee yet today, so that might be the problem).
>>
>> I see that spamdyke has this check as well (reject-missing-sender-mx).
>> I think it'd be good to let spamdyke handle this check, so it could be
>> overridden by a whitelist entry when appropriate. This would take care
>> of the cases which have pestered me in the past.
>>
>> However, this means that the check would not be done for authenticated
>> sessions, nor submissions, allowing messages with a malformed return
>> address (at least the domain part) to be sent out. I'm not so sure
>> this is a good thing, as bounces would fail and messages would
>> "vaporize".
>>
>> What am I missing?
>>
(Continue reading)

Permalink | Reply |

Gmane