Re: genuine email got blocked as spam2005-06-29 16:17:29
At 21:11 2005-06-29 +0000, Matthias Haeker wrote:
i hope i am on the right place for this question.
Sadly, no. Procmail is a tool for filtering mail - such as mail you receive. It won't change how your mail is delivered/relayed by your MTA. You should contact a list appropriate to the MTA you're using (Sendmail, Postfix, QMail, Exim, etc).
we have to forward email from a local mail server over a "smart relay" to the world.
I process a smart relay for a firm who gets their net hosting from some company whose entire IP range was DNSBLd because at one time the hosting company had a customer who was a spammer. AFAIK, that isn't the case anymore, but the netblock is still affected, and thus my client - who has a delegated block from that address range, is as well. In order to reliably send mail, he's got to relay through my service.
the email header will look like this on the receiving host Received: from xxx-yyy.de (xxx-yyy.de [252.252.252.252]) by anybody(_at_)world(_dot_)de (8.13.4/8.13.4) with ESMTP id j5T7jDIl015888 for <anybody(_at_)world(_dot_)de>; Wed, 29 Jun 2005 09:45:13 +0200 (CEST) (envelope-from someone(_at_)xxx-yyy(_dot_)de) Received: from xxx.de (xxx.de [220.127.116.11]) by xxx-yyy.de (8.13.4/8.13.4) with SMTP id j5T7j84I015870 for <anybody(_at_)world(_dot_)de>; Wed, 29 Jun 2005 09:45:11 +0200 (CEST) (envelope-from someone(_at_)xxx-yyy(_dot_)de)
I can understand the concern for exposing the actual IPs to snoopy people, but ultimatley, it's a LOT better if you just use REAL unaltered headers (except for the username portion of addresses). This would allow a knowledgeable person to check DNS for the hosts and offer suggestions that are pertinent - such as perhaps one of the IP ranged you're using is non-routeable (which would be a good reason to be relaying).
Is the relay host you refer to as "domain.smtp" on the same LAN as the mail host you refer to as "local.smtp"?
both smtp have fixed ip with mx dns and a record
fixed IP is good and all, but the actual addresses would be good to know.
the rest 5% Received there email from the local smtp
er, so 5% of the mail you send DOES NOT use the smart relay? If that's the case, then the mail host isn't on a non-routed IP block. It could however still be in a DNSBL. Perhaps your IP address is part of a dialup/broadband DNSBL, and so some sites are refusing the mail because it appears to be coming from a consumer-like origin?
i had to set the smtp host name of the local server to xxx.local or it didnt worked out. i need the tunnel or my own server didnt acceptet my authentication couse of the dns lookup check of the smtp host name anymore:)
Er, this is vague, but is sure seems to point to a bad DNS data. Perhaps some of the sites rejecting your mail are doing so because one of your hosts has invalid data? If you can't set up a trust relationship with another host with which you have a configuration relationship, something is wonky.
FTR, TLS is the appropriate way to establish a trust relationship between mail hosts, though it of course requires that both mail hosts be running an MTA supporting TLS. I use a TLS relationship to allow one listserver to accept mail from one other particular server claiming to be sending mail from that domain, but reject all other remotely originated messages claiming to be from the domain (users connecting using SMTP AUTH of course are permitted). This wipes out inbound forgeries from the domain (such as those annoying malware claiming to be from some administrative-like address telling you your account is suspended or your password has been changed and to open the attachment).
MDeferred: 450 4.1.0 <someone(_at_)xxx-yyy(_dot_)de>: Sender address rejected: unverified address: Address verification in progress
This looks a lot like a greymilter, or a "callback" system that attempts to negotiate an inbound message to your domain to confirm that mail is accepted at the address from which the messages are being sent (the "envelope from").
MDeferred: 450 <anybody(_at_)world(_dot_)de>: Recipient address rejected: Greylisted for 300 seconds
Well, this IS clearly greylisting. Your server should be attempting to resend the message a while later (typical sendmail config for instance would be 15 minutes), and at that time, the message should be successfully accepted by the remote server. Check the SMTP ids in your logs.
with the rest of the world it is still working.
Because EVERYBODY isn't implementing greylisting. I'm not keen on it because it significantly delays legitimate emails.
--- Sean B. Straw / Professional Software Engineering Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html> Please DO NOT carbon me on list replies. I'll get my copy from the list. ____________________________________________________________ procmail mailing list Procmail homepage: http://www.procmail.org/ procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail