???? ???????:
> ??, 2 ???. 2018 ?. ? 4:24, Wietse Venema <wie...@porcupine.org>:
>
> > ???? ???????:
> > > Hello,
> > >
> > > we have pretty complicated setup. when we change something, we can break
> > > something else. however, we can describe "what must work".
> >
> > In the case of email, this is usually tested by sending email and
> > monitoring one or more destination mailboxes, to determine if the
> > message is delivered in the expected time and with the expected
> > content.
> >
> > > is there a way of describing configuration testing like
> > >
> > https://openresty.gitbooks.io/programming-openresty/content/testing/test-nginx.html
> > > ?
> >
> > SMTP is a store-and-forward protocol, therefore server responses
> > alone cover only a small part of a complete email transaction.
> >
>
> I understand that HTTP and SMTP are different (while HTTP borrowed a lot
> from SMTP, like return status codes).
> what I did already is "sendmail -bt" (become test) mode. it allows to test
> some aspects of smtp rules (not many, mostly address manipulation).
Perhaps you mean 'sendmail -bv', as discussed in the example at the
end of ADDRESS_REWRITING_README. Postfix has no 'sendmail -bt' feature.
> what I would like to test are
>
> 1) some IP are allowed to relay, some are not allowed (i'd like to specify
> several IP addresses and see "relay allowed" or "relay not allowed")
That's what Postfix has the XCLIENT feature is for.
> 2) some domains should be delivered via LMTP, i.e. locally (I'd like to
> specify both local and remote addresses and see what happens)
Set up a 'local' and 'remote' mailbox. Or run the system in a VM
or container, and you have full control over all its network therefore
can simulate any environment.
> 3) DKIM signature is added to certain domains (via milter), I'd like to
> send test messages and see
Set up a mailbox and examine the result...
> well, at least "3)" can be tested via real use letters. not clear how to
> test "1)" and "2)"
>
> we did break overall config when changed "something". we do not want to
> break again.
Wietse
