<User> sorry i want to refer to this check http://abuse.net/relay.html <User> Relay test 9 <User> >>> RSET <User> <<< 250 flushed <User> >>> MAIL FROM:<spamtest@fuenlabradadigital.org> <User> <<< 250 ok <User> >>> RCPT TO:<"securitytest%abuse.net"> <User> <<< 250 ok <User> Relay test result <User> Hmmn, at first glance, host appeared to accept a message for relay. <User> THIS MAY OR MAY NOT MEAN THAT IT'S AN OPEN RELA
Qmail has a modular software design. It has a process that listens for incoming messages, called qmail-smtpd. It has other processes that enqueue the message (if qmail-smtpd accepts it), and others that process the queue. Each component of qmail is relatively simplistic, and may not have full knowledge of how the other components work.
qmail-smtpd accepts any message for any username with your list of acceptable recipient domains (control/rcpthosts). qmail-smtpd does no validation of the username on the left-hand side of the @ sign in an email address. It simply accepts the message, and hands it to qmail-queue for enqueueing; if the username turns out to be invalid, a bounce will be generated to the original sender.
Certain other MTAs (not qmail) have a "feature" by which senders may specify routing information in an e-mail address. For example, in the address
spamtest%abuse.net@some.real.domain
these other MTAs would accept the message, then relay it to the e-mail address
spamtest@abuse.net
by removing the local domain, and converting the % to an @. Qmail does not do this! However, the spam relay testing sites don't know that you are running qmail. When they submit a message to you using a percent-hack address, they can only see that you have accepted it; they don't know whether you are going to bounce it back, or relay it.
That's why some of the spam relay tests generate false reports of qmail being a relay (when it isn't); and why others generate ambiguous reports (like the one shown above). You, as the mail administrator, are expected to understand all of this.
If you do not like this behavior (and, in many cases, you do not want this behavior, since it causes lots of Joe Job spam-bouncing), then you must replace qmail-smtpd with something which is capable of rejecting invalid local usernames during the SMTP conversation.
Alternatives include:
- Replacing qmail-smtpd
qpsmtpd, a replacement for qmail-smtpd, written in perl
magic-smtpd, a drop-in replacement for qmail-smtpd, which lets you write your own validation program
You may be able to use QMail::Deliverable as the validator program.
- Unfortunately, it appears magic-smtpd development has been abandoned...?
Qsmtp, another qmail-smtpd replacement, in C
- Patching qmail-smtpd
qmail-verify, a patch to qmail-smtpd to do local name verifications