[conspire] (forw) [sorbs.net #212641] [Webform] SORBS registration systems sends RFC-ignorant mail

[Rick Moen]

Quoting Ruben Safir (ruben at mrbrklyn.com):

> Thanks.  I completely understand now.  A user though still must have a
> record on an authorized MX server.

Because of this talk of "having a record", I think you're still getting
hung up on some erroneous concept of "checking the user".  All that's
being checked is that the domain's MX accepts mail for the claimed
sender address.  That's it.  If an incoming SMTP connection is
attempting to deliver mail claimed to be from sender "foo at example.com",
then my MTA should be able to connect to an MX for domain example.com
and verify that it's willing to accept responses to mailbox
"foo at example.com".  The MX doesn't need to know anything about user Foo,
and Foo need not have a "record or account" there.  All that matters is
that the MX be willing to say "Sure, I'll accept mail addressed to
mailbox 'foo at example.com'".


> So if one just sticks a GNU Server on a verizon cunsmer grade FIOS
> network and sends mail out without having a record or account on the
> verizon network, they're shot...nothing is getting through.

You're not getting this.  Let's try this from first principles.

The domain-owning user either secures a fixed, static IP from Verizon
Broadband on which his/her SMTP host will live -- case A -- or
negotiates an agreement with Verizon to virtual-host his/her
SMTP-handling domain on Verizon's fixed-IP servers -- case B.  (It is
not possible within reason to operate an SMTP host on dynamic IP.  There
are people who try.  They are deluded.)

In case A, the user points the "A" record for his/her mail-sending
domain (example.com)[1] at the static IP in question, and optionally
creates a matching "MX" record (recommended, by the way).  The mail
from "foo at example.com" originates from that IP.  The host also accepts
return mail, and therefore is the place where callouts verifying the
deliverability of "foo at example.com" will check.

In case B, the user points the "A" and optional "MX" records at one of
Verizon's large mail hosts, after verifying with them that they're 
willing to forward its outbound mail and accept mail addressed to it.
The user generates on his/her dynamic-IP desktop box the outbound mail
from "foo at example.com", and relays it through one of Verizon's big
mail-handling hosts, which is willing to handle it because it originated
on a Verizon IP and is addressed from one of the domains Verizon have in
their MTA allowed-relay table.  Because that host is where the MX/A
records point, it's where callouts verifying the deliverability of
"foo at example.com" will check -- and it'll say "Sure, I'll accept mail
for 'foo at example.com'" because that's in its table of mailboxes the
Verizon MTA handles.

If perchance you are not talking about a _domain-owning_ user, then
that's case C:  The user generates on his/her dynamic-IP desktop box the
outbound mail from "foo at verizon.com", and relays it through one of
Verizon's big mail-handling hosts, which is willing to handle it because
it originated on a Verizon IP and is addressed from domain verizon.com.
Callbacks to verifying the deliverability of foo at verizon.com will come
to one of Verizon's big mail-handling hosts to which one of the MX
entries points for domain verizon.com.  It will say "Sure, I'll accept
mail for 'foo at verizon.com'", becuase that's in its table of mailboxes
the Verizon MTA handles.

> If they fix their  'From' line to an official verizon email account,
> or have an mx record set up somewhere in the world for their supposed
> sending domain, they are good to go.

If the domain-owning user does _not_ have an MX or A record set up for
the claimed sending domain, then he/she is by definition sending bogus,
forged SMTP mail, and I definitely do not want my MTA accepting it.  You
wouldn't want yours to accept it, either.