[Asrg] RMX example

[Hadmut Danisch <[e-mail]>]

On Tue, May 06, 2003 at 03:56:40PM -0400, Daniel Feenberg wrote:
>
> It would probably be usefull if you posted a few sentences to go
> over exactly what the validation steps are for a site using RMX
> to control incoming mail. 


OK.

Let's go through an example (not yet implemented)



1. Authorized mail
  Imagine I am sending you an email.

  My MTA opens an SMTP connection to your
  MTA (where the MX of your domain points to). Your MTA
  sees an SMTP connection from 213.133.101.23. Nothing
  hapens so far. HELO or EHLO doesn't matter.

  Now my MTA issues the SMTP command

    MAIL FROM: <[e-mail]>

  and waits for the reply code of your MTA.
  This is where your MTA performs the RMX lookup:

  The sender address [e-mail] has the
  domain part danisch.de. So the RMX record for danisch.de 
  is queried. 


  danisch.de IN RMX  ( relays.rackland.de  relays.somecompany.com )


  because I might use the relay machines of Rackland and SomeCompany
  to deliver mail. But I do not want to update my zone table every
  time Rackland and Somecompany change their IP addresses. So
  it is the task of Rackland's and SomeCompany's administrations
  to keep the APL records below up to date.


  In a second step, the APL records are fetched:


  relays.rackland.de    IN APL ( 213.133.101.23/32 )
  relays.somecompany.de IN APL ( ...some addresses )

  After the first APL record the check is finished because it
  positively covers the IP address where the SMTP connection came
  from.

  -> your MTA learned that my MTA with that particular IP address
     was authorized to use danisch.de as a sender domain.




2. Unauthorized mail / Spam

   Now a second SMTP connection is opened to your MTA, 
   this time from 62.226.51.34. Again, nothing happens so 
   far. 

   Now the sending MTA issues the SMTP command
 
      MAIL FROM: <[e-mail]>

   (which is unauthorized)

   Now your MTA fetches the RMX and APL records as described above.
   But these APL records do not cover the IP address 62.226.51.34

   -> Now your MTA learned that the message came from an IP 
      address that was not authorized to send

   -> It's up to you and your local rule set what to do with it,
     whether to reject, drop, tag, run through a content filter or 
     whatever.




Should be enough to understand the basic principle.
(For easier reading I simplified the APL syntax a little bit)

Hadmut



_______________________________________________
Asrg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg