- Previous message: Rocco Scappatura: "RE: rely recipient verification (Was: Increasing throuput)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
|
|
|
From: Rocco Scappatura (no email)
Date: Mon Oct 01 2007 - 04:07:22 EDT
> I suspect your check_client_access was used to implement a
> permit_mynetworks. Make sure this the case and reorder your checks:
>
> reject_unauth_destination is used to reject relay. since it
> is the first one in your smtpd_recipient_restrictions, nobody
> can relay via this smtpd.
>
> It is recommended that you enable the submission port (587)
> and use it to relay mail (but not accept mail from the public).
How could I activate this port?
> In the meantime, move the check_client_access that implements
> permit_mynetwork and put it before reject_unauth_destination.
>
> Please note that checks are performed in the order they are found.
The behaviour has picked up (I have no more "Relay access denied" errors
for my clients, when they try to send message trhoug my SMTP server).
But I'm still a little bit sospicious about the recipient validation for
my 'external domains'.
For example, for an external domain of mine, say 'domain.it', I get:
Oct 1 09:40:13 av4 postfix/smtpd[13993]: NOQUEUE: reject: RCPT from
unknown[87.250.102.202]: 450 4.1.1 <>:
Recipient address rejected: undeliverable address: host
mail.bontempi.it[195.96.202.54] said: 550
<>: Recipient address rejected: User unknown
in virtual alias table (in reply to RCPT TO command);
from=<> to=<>
proto=SMTP helo=<ybvs>
And this is OK (It seems to me that it is my SMTP server that reject the
message for the inexistant address of my external domain). But when I
have tried for other external domains and it doesn't seems to me that
that mail server have the same behaviour. Infact I get:
Oct 1 09:58:14 av4 postfix/smtp[19942]: 687F1750193:
to=<>, relay=10.30.32.7[10.30.32.7]:25,
delay=0.55, delays=0.11/0.29/0.12/0.03, dsn=2.0.0, status=deliverable
(250 ... Recipient OK)
Whatever it is the recipient.. I suppose that in this case the receiving
mail server is guilty of this mesleading behaviour..
Maybe he has a catchall for his domain or won't verifies its recipients?
rocsca
|
|
|