Subject: Re: [Asrg] MXs Used As Authentication - Why RMX?

From: "Peter J. Holzer" <[email-masked]>
Date: Mon, 25 Aug 2003 12:28:45 +0200

On 2003-08-25 09:13:27 +0100, Sabahattin Gucukoglu wrote:
> I've tried hard to work out a requirement for an additional DNS RR (RMX - 
> Danisch Draft) for authentication, but can't understand why MXs alone 
> can't be used.  I must be missing something somewhere.  Why can't you just 
> resolve the given envelope sender domain, check all of the MXs hostnames 
> and see if any of them matches your connecting machine's IP after 
> resolution to addresses? 
[...]
> Now, so long as all possible output relays for a domain are an MX,
> there's no problem, right? (Or is this not what happens in the
> real-world?)

It does happen in the real world, and it is probably even the most common
case. But it is not the only case. Some organizations have different
mail servers for incoming and outgoing mail traffic. In this case only
the servers for incoming mail are listed in MX records, but mail always
never comes from those. 

Also, you cannot determine from the existence of an MX record that all
mail must come from a certain set of hosts. We have MX records for our
domains, but people working at home are encouraged to use the SMTP
server of their internet provider. 

Somebody suggested picking a high priority value (e.g., 54321) to mean
"this is an RMX". This would probably work, but it is a kludge.

	hp

-- 
   _  | Peter J. Holzer    | Humor ohne Emoticons ist trockener Humor.
|_|_) | Sysadmin WSR       | 
| |   | [email-masked]         |	-- Toni Grass in aip
__/   | http://www.hjp.at/ |

---

From: Bill Cole <[email-masked]>
Date: Mon, 25 Aug 2003 07:28:44 -0400

At 9:13 AM +0100 8/25/03, Sabahattin Gucukoglu wrote:
>Now, so
>long as all possible output relays for a domain are an MX, there's no
>problem, right? (Or is this not what happens in the real-world?)

It is not what happens in the real world. For sites handling 
significant mail volume, outbound mail and inbound mail are large 
enough and different enough in their ideal system design that it 
makes sense to have them handled by different systems. Spam has also 
spurred that split, since it is more important for most sites that 
inbound mail has spam filtering than outbound mail, and it is 
simplest to just push out mail through a system without such filters.

-- 
Bill Cole
[email-masked]

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

---

From: "Christopher Bird" <[email-masked]>
Date: Mon, 25 Aug 2003 06:41:33 -0500

I believe it is fairly common for inbound and outbound systems to be
quite different. In fact, I see that even though this mail is coming
from my MSN account ([email-masked]), I am unable to use the MSN SMTP
service. MSN has a rule that demands that my current IP address be an
MSN recognized IP address before they will accept email. In other words
they will not relay from anyone. So my POP3 server is an MSN POP3
server, but my SMTP server is my cable provider's SMTP server. All this
is further complicated because for my home business, using an entirely
different set of domains, my SMTP and POP3 servers are my own domain
servers hosted elsewhere. 

Chris 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Sabahattin Gucukoglu
> Sent: Monday, August 25, 2003 3:13 AM
> To: [email-masked]
> Subject: [Asrg] MXs Used As Authentication - Why RMX?
> 
> 
> Hi peeps,
> 
> resolution to addresses?  The hostname could come either from 
> the SMTP 
> client greeting (helo/ehlo) or the sender domain, and MX 
> resolution could 
> be recursive (including checks to ensure no infinite 
> recursion).  Now, so 
> problem, right? (Or is this not what happens in the 
> real-world?)  Even if 
> an IP's RDNS resolves to a name completely different of the 
> domain, which 
> happens for people using DDNS on fast connections to the net 
> (cable/etc), 
> the solution still works.  It just needs coordinated 
> configuration of MTAs 
> properly (so that ehlo/helo resolves to owner FQDN) and the 
> checking code 
> which would ensure that a hostname given was stripped to form 
> all possible 
> domains for checking (ensure that host doesn't get refused if 
> a relay with 
> the same domain name - EG xyz.example.org checked as example.org).
> 
> Anything need clarifying?  Please ask.  I'll be back when the 
> flames die 
> down a little and someone has put the idea right out...  If my 
> understanding is messy, please let me know where. :-)
> 
> Cheers,
> Sabahattin
> 
> -- 
> 
> Thought for the day:
>     The only thing that hurts more than paying income tax
>     is not having to pay income tax.
> 
> Latest PGP Public key?  Click: 
> <mailto:[email-masked]>
> and send that 
> message as is.
> 
> Sabahattin Gucukoglu
> Phone: +44 (0)20 7,502-1615
> Mobile: +44 (0)7986 053399
> http://www.sabahattin-gucukoglu.com/
> E-mail or MSN Messenger: <[email-masked]>
> 
>

---

From: Brad Knowles <[email-masked]>
Date: Mon, 25 Aug 2003 15:11:34 +0200

At 7:28 AM -0400 2003/08/25, Bill Cole wrote:

>  makes sense to have them handled by different systems.

	This issue is dealt with in 
<http://www.irtf.org/asrg/draft-vixie-repudiating-mail-from.txt>.

	As I see it, one primary problem with this draft is that it 
breaks the most common form of mailing lists -- aliases.

	This draft also prevents people from being able to legitimately 
transmit e-mail using domain names that they don't control, via other 
servers.  It is not at all unusual for me to go travelling somewhere 
and want to continue to use my normal e-mail address, but use the 
local mail relay services available from the provider I'm using at 
the moment.

	Same for third-party webmail services.

	You would have no choice but to have SMTPAUTH or TLSSMTP 
available for the official relays for your domain, and to be able to 
guarantee that you can always get through to them using these 
features, as opposed to being transparently proxied somewhere else 
(something that more and more providers are starting to do).

	In my case, the Skynet mail servers are on many black lists, 
because there are a large number of customers (over one million), a 
small percentage of whom generate spam (or are open relays for spam). 
But that small percentage is enough to get the main mail servers 
effectively permanently black listed, even if this is a serial 
process -- get off the black list that resulted from customer A, get 
right back on the black list because of customer B.

	There are some places out there that use the rfc-ignorant.org 
domain-based black lists, and I can't get mail to those people using 
this account, no matter what relay I use (yes, Skynet is stupid 
enough to not have a functioning abuse@ address).

	But for everyone else, I can route my outbound mail through an 
ssh tunnel to a server I have elsewhere in the US, and at least I'm 
not hindered by the fact that the Skynet servers are on many of the 
blacklists in the world.

	I don't see this sort of solution being feasible.  The legitimate 
third-party relay problem is a tough one to solve.

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)