On Thu, 2008-02-21 at 13:48 +0100, Yves Goergen wrote: > I don't know anybody who really cares about that RFC postmaster account.
Well... there's a lot that can be said about this, but it's been said
elsewhere so I'll leave that argument for another time.
> My idea was, letting the initial SMTP sender wait a bit shouldn't be too
> hard. So can't Exim just get the message and try to deliver it at once
> instead of confirming it and delivering later? So when somebody passes
> my server a message, an SMTP chain is established with the message going
> forward and possible errors passed back. This way no bounce messages are
> necessary. It can be problematic for long chains, but usually it's the
> common way "sender" -> "name@official-domain" -> "name@private-hoster"
> and then it ends.
Problematic in so many ways: you don't know how long the forward chain
is, you don't know how many servers are involved, you don't know whether
or not they will respond in a timely fashion, you don't know whether or
not their network is reachable, you don't know if at some point in the
chain someone is doing "accept-n-bounce", you don't know if somewhere
down the line the message is being handled by a mailing list or other
alias type "exploder" which generates tens, hundreds, thousands of
messages... to list just a few.
SMTP is a "best efforts", store-and-forward protocol, by definition. It
isn't a real-time messaging system (which would have the safeguards you
want built in).
What you *can* do, which emulates the requirement you have, is to do
call-forward verification using something like:
but you should *only* use this if you know where the messages are going
- do not use it for sender verification, or you'll quickly end up listed
on some DNSBLs (again, another argument, another time, several other
places).
You will only be able to do this if the forwarding is done in a redirect
router, and I recommend you read the docs to work out the best way for
you.
