Le 22/02/2013 16:09, Geoff Shang a écrit :
> I guess the following makes sence. I was just wondering if this is
> intended behaviour, and if so, why.
> As I posted in my previous messages, I'm setting up mail for a mail
> hosting solution that will host any number of domains. The mail
> itself will be scanned on another box and stored on yet another, so
> all hosted domains will be relayed.
> After fighting to get relay_domains working propperly, I discovered
> that using /usr/sbin/sendmail to send a message to foo@...
> (i.e. a non-existant user on a relay_domain), postfix would try to
> deliver the message to our internal servers, even though the user
> doesn't exist. Looking at the LDAP logs revealed that LDAP wasn't even
> being queried for the recipient.
> I had access to other servers which correctly reject mail received via
> SMTP, so was able to check my configuration.
> I then realised that reject_unlisted_recipient is an SMTPD
> restriction, and that local mail likely bipassed this check. So I
> tried establishing an SMTP session from the local host, and discovered
> that SMTP rejected the mail as expected.
> I also verified that a known working configuration also seems to not
> check virtual_mailbox_maps when processing mail submitted via
> /usr/sbin/ssendmail. It resulted in a bounce message.
> So I was wondering if this is expected behaviour or not. Maybe
> there's a good reason for it. Maybe it's an oversight. Or maybe it's
> a bug that's been fixed since version 2.7.1.
> For now, I will make sure to test my configurations using SMTP rather
> than local submission.
since the sendmail command has been used for ages by programs such as
cron, its behaviour may not be changed. in particular, there is no way
for sendmail to tell cron (or whatever): no, I wo't take it, find out
some other way. if it did, sysadmins will lose important information.
Note that you can still configure sendmail to pass mail to an smtpd
listener (by using a -o content_filter under the pickup service).