At 15:16 9/26/2003, Tracy wrote:
>I've been looking over the problem of RFC compliance for postmaster@,
>abuse@ and a couple of other aliases, and I'm wondering if there's an
>existing configuration option that can be used to allow mail - even from
>addresses in spammers.tab and spam-addresses.tab - that are addressed to
>these RFC mailboxes?
>
>If there's not a configuration option to allow this, I guess I could go in
>an modify the source - but I'm going to have a hard time figuring how to do
>this, without making all the other blocking ineffectual. I suppose I could
>do the checks in RCPT TO processing, and accept/reject based on that...
Forgive me replying to my own message, but I've taken a look at the code
and I don't see anything that would allow certain addresses to override
blocking methods. So, I've taken a look through the code and through my
"wish list", and the list of tests (including where the tests would be
performed) that I would like the option to configure are listed below.
Note: I know that the feature set for 1.x is fixed, no new features will be
added - I'm planning to (eventually) modify the source of either 1.16 or
1.17 to account for all this - but I'm detailing the tests here in hopes
that they might be considered for inclusion in 2.x.
Each of these tests would be optional (or perhaps an option to handle
groups of tests), with options to enable/disable them in server.tab, and
the way I currently envision these tests working would require adding a new
member variable to the SMTPS structure - FailCode - and a number of
constant declarations for failure code reasons. There would also be a
couple of new tab files - spam-helo.tab, spam-dns.tab, and
error-override.tab - the first two of these being similar in nature to
spam-addresses.tab, and the last one being a list of recipients who would
receive mail without regard to test failures.
The tests I would like to perform are:
Connection received:
IP in spammers tab --> SMTPS.FailCode |= SMTP_FAIL_IP_SPAMMER
No RDNS --> SMTPS.FailCode |= SMTP_FAIL_IP_RDNS
RDNS matches spam-dns.tab --> SMTPS.FailCode |=
SMTP_FAIL_IP_RDNS_SPAMMER
IP -> PTR -> A, IP doesn't match A --> SMTPS.FailCode |=
SMTP_FAIL_IP_BADPTR
IP in DNSBL --> SMTPS.FailCode |= SMTP_FAIL_IP_MAPS (probably need
to store the DNSBL name, too)
HELO/EHLO command:
HELO name is an IP address --> SMTPS.FailCode |= SMTP_FAIL_HELO_IPADDR
HELO name in spam-helo.tab --> SMTPS.FailCode |=
SMTP_FAIL_HELO_SPAMMER
HELO name not valid FQDN --> SMTPS.FailCode |= SMTP_FAIL_HELO_FQDN
HELO name doesn't resolve --> SMTPS.FailCode |= SMTP_FAIL_HELO_DNS
HELO name lookup doesn't match connected IP --> SMTPS.FailCode |=
SMTP_FAIL_HELO_NOTPEER
MAIL FROM command:
Address == "<>" --> SMTPS.FailCode |= SMTP_FAIL_MAIL_NULL_SENDER
Raw address in spam-addresses.tab --> SMTPS.FailCode |=
SMTP_FAIL_MAIL_SPAMMER
Address domain doesn't have MX record --> SMTPS.FailCode |=
SMTP_FAIL_MAIL_MX
Address domain doesn't have A record --> SMTPS.FailCode |=
SMTP_FAIL_MAIL_DNS
Note that the result of a previous test may, or may not, affect whether
later tests are performed - for instance, if the MAIL FROM address domain
has a MX record, there's no need to check for an A record.
Once we get to RCPT TO:, we perform an additional check after the "Check
FORWARD PATH" check, but before logging the session. This check tests the
FailCode values to determine whether or not we should issue a failure code
(and what kind), and additionally checks to see if the RCPT TO address is
in error-override.tab (which would allow the recipient even in the case of
test failure).
So, what I'm looking for here is some sanity checking to see if this kind
of thing seems reasonable - I know that not everyone will like every test
(that's why there would be options to enable or disable various tests), but
I'm looking specifically to know if there are tests here which are
*completely* useless, or if I've missed something that is useful and should
be included. Oh, and I know that some of these tests break (or seriously
bend) RFC requirements (such as null sender and some of the HELO tests).
Feel free to mention it, though...:)
Anyone?
Tracy
-
To unsubscribe from this list: send the line "unsubscribe xmail" in
the body of a message to [EMAIL PROTECTED]
For general help: send the line "help" in the body of a message to
[EMAIL PROTECTED]
