Re: [Fwd: Re: [SM-PLUGINS] Re: sqmail / username plugin]

[p d. t. <pdo...@an...>]

Jo=E3o,

> without wanting to start hard discussion again I send you some=20
> excerpts from RFC 2505, may be worth reading it entirely, not=20
> forgetting that this orientations are thought for the receiver MTA=20
> (in terms of MTA-MTA traffic), resulting in obvious advices for the
> sender MTA (controlling the UA-MTA traffic). Since the UA only sends
> to the sender MTA and retrieves what the MTA received for his
> account, the UA is a passive part in this game and the MTA should
> decide if the gotten traffic, either form the UA or another MTA is
> legal within what it can check.

Following such logic, which isn't bad, if you want a really tightly
configured MTA, you should actually make sure your MTA is configured to
deal properly with the "bad" From: fields that your SM installation is
producing.  If the UA is "passive", then fixing it is a secondary
concern (but again, read more about SM plugins and config options and it
can be set up to do what you need w/out so many troubling emails).

> In the memo we sometimes use the term "host name" or "domain name"=20
> which should be interpreted as a Fully Qualified Domain Name, FQDN.=20
> By this we mean the name returned from the DNS in response to a PTR=20
> query (.IN-ADDR.ARPA), i.e. when an IP address is translated to a=20
> name, or we mean a name with a DNS A or MX record associated to it=20
> RFC1034, [5], and RFC1035, [6].
>=20
>>>> An IP address can have only one valid reverse record=20
>>>> (.in-addr.arpa),
>=20
> means that the MX records of virtual domains probably have not the=20
> same domain portion as the sender or receiver address. These MTAs=20
> must be careful configured to relay for the hosted domains (in and
> out) but not becoming open-relays. <<<

Pretty easy with most MTAs these days.

> Our basic assumption is that refuse/accept is handled at the SMTP=20
> layer and that an MTA that decides to refuse a message should do so=20
> while still in the SMTP dialogue. First, this means that we do not=20
> have to store a copy of a message we later decide to refuse and=20
> second, our responsibility for that message is low or none - since we
>  have not yet read it in, we leave it to the sender to handle the=20
> error. ... In an SMTP session we have 4 elements, each with a varying
>  degree of trust: 1)  "HELO Hostname"           Easily and often=20
> forged. 2)  "MAIL From:"              Easily and often forged. 3)=20
> "RCPT To:"                Correct, or at least intended. 4)=20
> SMTP_Caller (host)        IP.src addr OK, FQDN may be OK. Since 1)=20
> and 2) are so easily and often forged, we cannot depend on them at=20
> all to authorize usage of our host as Mail Relay.
>=20
>>>> SInce this is so obviously the sender MTA should control better
> mail received from UAs for 1) and 2) what definitly would reduce=20
> incidents<<<

Sure, but what you continue not to hear is that many SM admins *NEED*
the ability to "forge" the From: header so they can do things like
better filter their mail, run software like TMDA and whatnot.  A
"forged" From: doesn't always mean that it is an *invalid* From: and
doesn't mean that it is spam or otherwise malicious.  As long as the
sending MTA is set up with correct authentication and a trusted user
base, this is not a problem.  You keep assuming that because *it is
possible* to either misconfigure a system or for a malicious user to
take advantage of a losely configured system that software like SM
shoulld limit this kind of useful flexibility.  By that same logic, you
should go try to tell the authors of all the popular MTAs that they
should take out all code that allows an MTA to be an open relay.  Good lu=
ck.

> The MTA SHOULD be able to perform a simple "sanity check" of the=20
> "MAIL From:" domain and refuse to receive mail if that domain is=20
> nonexistent (i.e. does not resolve to having an MX or an A record).
>=20
> If the DNS error is temporary, TempFail, the MTA MUST return a 4xx=20
> Return Code (Temporary Error). If the DNS error is an Authoritative=20
> NXdomain (host/domain unknown) the MTA SHOULD still return a 4xx=20
> Return Code (since this may just be primary and secondary DNS not=20
> being in sync) but it MAY allow for an 5xx Return Code (as configured
>  by the sysadmin).
>=20
>>>> that in addition to the advice using FQHN. Obviously
> webmail.domain.com is in most cases not a domain name but a host name
>  so probably it will be rejected by most MTA by default (eg.=20
> sendmail), especially if it is only a http virtual host but not
> beeing a FQHN <<<
>=20
> ... The MTA SHOULD allow outgoing mail to have its <local-part>=20
> verified so that the sender name is a real user or an existing alias.
>  This is basically to protect the rest of the Internet from various=20
> "typos" ... As always this can be overcome by spammers really wanting
>  to do so, but with more strict rules for relaying it becomes harder
>  and harder. In fact, catching "typos" at the initial (and official)
>  mail relay is in itself enough motivation for this recommendation.=20
> ... The common use of forged "MAIL From:" and "From:" addresses puts=20
> the blame on innocent persons/hosts/organizations. This is bad for=20
> reputations and may affect business relations.
>=20
>>>> Since this is bad and and since the usable methods of a=20
>>>> receiver MTA
> are certainly limited an important part of protection lays at the=20
> sender MTA level. <<<

Of course sending MTAs should be properly configured.  Most of them are.
  Even ones with SM running virtual domain plugin software that change
the $domain variable.  Just because it is possible to screw up plugin
installation like you seem to have done (sorry, not trying to be rude)
does not mean it's SM's fault.  Instead of telling us to "fix" our
software, *you* should do more research on how you can better configure
the software to work like it should - it is certainly capable of doing so=
.

I like the idea of a free society were there is a basic level of trust
amongst our fellow beings.  Your approach insists that "we can't trust
anyone" and that we must prohibit any behavior that deviates from the
norm just because it *might* be ill-intentioned.  To me, that's a boring
and close-minded world...  hmmm, sometimes the USofA mirrors your
approach too much for my taste.

  - Paul