On 2 Jun, Dallman Ross wrote:
| Justin Shore wrote:
|
| [...]
|
| > It appears you made a direct-to-MX connection to send this one
| > message.
|
| No, I didn't. I use the SMTP server at my main shell provider.
| But I log in with T-Online in Germany.
|
| > Your dynamically assigned IP is in dialups.relays.osirusoft.com,
| > dialups.visi.com, and dnsbl.njabl.org (note that the last two
| > DNSBLs were added by me manually and the score I chose for all
| > those DNSBLs was 1).
|
| I have no real idea what you're talking about with manual scores.
| I don't use any blacklists, and certainly not any for dynamic
| dial-ups at major ISPs. Talk about asking for false positives!
|
Butting in with a between-the-lines assumption (so it may be wrong) ...
Dallman's messages are not direct to MX. If you look at the headers
the first Received: header chronologically (bottom most in his
messages) shows his dip.t-dialin.net IP handing the message to
mailspool2.panix.com, which hands it to mail1.panix.com (next Received:
header up), which hands it to relay1.rwth-aachen.de (next one up) for
delivery to the list server. He is clearly not delivering direct to MX
but is configured to use his provider's smtp server for outgoing mail.
My guess is a "shoot first, ask questions later" recipe is looking for
t-dialin.net in ANY Received: header, when the intended use of a dnsbl
configured for use by an SMTP server would be to check only against the
last hop. I interpret Justin's statement above that this recipe was
added by him to mean he rolled it himself as opposed to it being a part
of SA. If so it's probably broken. If it's SA, then SA is defective.
This will punish anyone who uses an ISP listed in a dnsbl, even if
they're properly using the provider's server.
I'm all for people fighting as aggressively as they choose with their
own mail. I have blocks in my access.db that many people would frown
upon, including dip.t-dialin.net. Tough beans. But Dallman has no
problem sending mail to me because he does so through his ISP. You
can't punish someone for using a particular ISP. (Well you can, but I
doubt that's the intent here.) Searching for any Received: header that
matches any dnsbl entry punishes not just abusers, but responsible users
of that ISP. I know that some dnsbls like spews consider collateral
damage like this ok. I'm not entirely unsympathetic to that view and am
not arguing against that here (and won't participate in any follow-up
on that off-topic and unresolvable debate). What I'm saying is that I
suspect this is an unintended consequence of an ill-considered recipe.
There was a thread in March and April of this year under the subject
"Using Procmail for RBL Blacklists". I haven't heard otherwise, so
think it safe to assert there's a solution there that correctly extracts
the IP number of the machine that hands the message to your server. It
handles deliveries to either primary or secondary (then to primary) MX,
and should be readily adaptable for anyone wanting to run dnsbl checks
from procmail in a way that's consistent with how the same would be
done by a mail server. It should make it possible to avoid unintended
collateral damage caused by a draconian check of all Received: headers.
--
Email address in From: header is valid * but only for a couple of days *
This is my reluctant response to spammers' unrelenting address harvesting
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail