Re: genuine email got blocked as spam

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 [123.123.123.123])
>         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