On Mon, 27 Sep 1999, Gary Palmer wrote:
> How do you handle this at the minute? I see this as a general problem
> of SMTP-time validation. e.g. you could have an alias which expands
> to multiple local accounts, but not all of them exist. However, you
> can't reject the message in the SMTP transaction as there are valid
> local recipients.
Correct. The way Exim currently works is that it doesn't reject at SMTP
time if the local part is a valid alias. If it turns out that some or
all of what it expands into is undeliverable, then it generates a bounce
message and returns it to the sender. This is all perfectly in
accordance with the RFCs. If everybody followed the rules and put usable
return addresses on their mail there would be no problem.[*]
> In either case, whatever the `virtual domain' rewriting does, the
> local part may not exist. I believe the correct handling of this
> would be to return a 550 if none of the aliases exist.
That is *a* correct handling, not *the* correct handling. It is
perfectly correct to accept any address at SMTP time and then generate a
bounce later. From RFC 1123:
5.2.7 RCPT Command: RFC-821 Section 4.1.1
A host that supports a receiver-SMTP MUST support the reserved
mailbox "Postmaster".
The receiver-SMTP MAY verify RCPT parameters as they arrive;
however, RCPT responses MUST NOT be delayed beyond a reasonable
time (see Section 5.3.2).
Therefore, a "250 OK" response to a RCPT does not necessarily
imply that the delivery address(es) are valid. Errors found
after message acceptance will be reported by mailing a
notification message to an appropriate address (see Section
5.3.3).
----------
[*] We used not to verify at RCPT time. This has a number of advantages.
It speeds up the SMTP transaction. Also, you can send back a more
friendly message than "550 User Unknown". We have some paragraphs about
the format of our email addresses, likely typos people make, and how to
find people at Cambridge. I know this was useful because we used to get
the occasional "thank you" in response. However, once the spammers got
going with their junk that has undeliverable sender addresses, we had to
turn on receiver_verify just to stop our queues filling up with
undeliverable bounces. I resent this, because it has forced us to
degrade the quality of service we provide.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
