smtp_upstream -> smtp_downstream

Terminology is confusing.

HACKING.md

@@ -69,9 +69,9 @@ be fetched by any name).
 
 Some modules attach additional meaning to names. This is generally accepted
 since it is better to have only a single instance managing one resource. For
-example, module instance implementing forwarding to the upstream server can not
+example, module instance implementing forwarding to the downstream server can not
 reasonably enforce any limitations unless it is only one instance "controlling"
-that upstream. Unique names requirement helps a lot here.
+that downstream. Unique names requirement helps a lot here.
 
 "Semantical names" idea explained above is not applied when modules instances
 are defined "inline" (in place they are used in). These instances have no

maddy.go

@@ -22,7 +22,7 @@ import (
 	_ "github.com/foxcpp/maddy/storage/sql"
 	_ "github.com/foxcpp/maddy/target/queue"
 	_ "github.com/foxcpp/maddy/target/remote"
-	_ "github.com/foxcpp/maddy/target/smtp_upstream"
+	_ "github.com/foxcpp/maddy/target/smtp_downstream"
 )
 
 type modInfo struct {

man/maddy-targets.5.scd

@@ -171,22 +171,22 @@ Enable verbose logging.
 
 Set location of the MTA-STS policies cache directory.
 
-# SMTP transparent forwarding module (smtp_upstream)
+# SMTP transparent forwarding module (smtp_downstream)
 
 Module that implements transparent forwarding of messages over SMTP.
 
 Use in pipeline configuration:
 ```
-deliver_to smtp_upstream tcp://127.0.0.1:5353
+deliver_to smtp_downstream tcp://127.0.0.1:5353
 # or
-deliver_to smtp_upstream tcp://127.0.0.1:5353 {
+deliver_to smtp_downstream tcp://127.0.0.1:5353 {
   # Other settings, see below.
 }
 ```
 
 Use as a top-level definition:
 ```
-smtp_upstream amavisd {
+smtp_downstream amavisd {
     targets tcp://127.0.0.1:5353
 }
 
@@ -196,7 +196,7 @@ somewhere_else {
 ```
 
 ```
-smtp_upstream {
+smtp_downstream {
     debug no
     tls_client {
         ...

module/module.go

@@ -6,7 +6,7 @@
 // Each interface required by maddy for operation is provided by some object
 // called "module".  This includes authentication, storage backends, DKIM,
 // email filters, etc.  Each module may serve multiple functions. I.e. it can
-// be IMAP storage backend, SMTP upstream and authentication provider at the
+// be IMAP storage backend, SMTP downstream and authentication provider at the
 // same moment.
 //
 // Each module gets its own unique name (sql for go-imap-sql, proxy for

target/smtp_downstream/sasl.go

@@ -1,4 +1,4 @@
-package smtp_upstream
+package smtp_downstream
 
 import (
 	"github.com/emersion/go-sasl"

target/smtp_downstream/smtp_upstream.go

@@ -1,4 +1,4 @@
-// Package smtp_upstream provides smtp_upstream module that implements
+// Package smtp_downstream provides smtp_downstream module that implements
 // transparent forwarding or messages to configured list of SMTP servers.
 //
 // Like remote module, this implementation doesn't handle atomic
@@ -6,7 +6,7 @@
 //
 // Interfaces implemented:
 // - module.DeliveryTarget
-package smtp_upstream
+package smtp_downstream
 
 import (
 	"crypto/tls"
@@ -40,7 +40,7 @@ func NewUpstream(_, instName string, _, inlineArgs []string) (module.Module, err
 	return &Upstream{
 		instName:   instName,
 		targetsArg: inlineArgs,
-		log:        log.Logger{Name: "smtp_upstream"},
+		log:        log.Logger{Name: "smtp_downstream"},
 	}, nil
 }
 
@@ -81,7 +81,7 @@ func (u *Upstream) Init(cfg *config.Map) error {
 }
 
 func (u *Upstream) Name() string {
-	return "smtp_upstream"
+	return "smtp_downstream"
 }
 
 func (u *Upstream) InstanceName() string {
@@ -230,5 +230,5 @@ func (d *delivery) Commit() error {
 }
 
 func init() {
-	module.Register("smtp_upstream", NewUpstream)
+	module.Register("smtp_downstream", NewUpstream)
 }