Subject: [Asrg] 6. Proposals - Trust of Addressing Information SMTP Extension

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 04 Sep 2003 22:16:37 -0400

Abstract of the Internet Draft 
(http://www.ietf.org/internet-drafts/draft-pelletier-smtp-trust-00.txt):

Abstract
    This document defines an SMTP service extension [ESMTP] whereby an
    SMTP client may establish a trust relationship with the server
    attesting its confidence in the validity of the originator of a
    message.  This confidence, or its absence, can then be used to
    mitigate the cost of undesirable messages (primarily spam) without
    disrupting operations between, or with, SMTP implementations not
    supporting the extension.

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

---

From: "Marc A. Pelletier" <[email-masked]>
Date: Sun, 7 Sep 2003 01:59:00 +0000

Hello.

I feel it is important to point out that the I-D currently avaliable in the 
directory is outdated; I expect the -01 version should be avaliable shortly 
depending on how quickly it is processed.

There were a number of fatal flaws in the original version which have since 
been addressed.

Until the draft is avaliable in its official resting place, it can be read at 
http://free.hostdepartment.com/m/mapelletier

-- Marc A. Pelletier
   Ecole de Technologie Superieure

---

From: "Marc A. Pelletier" <[email-masked]>
Date: Sun, 7 Sep 2003 10:49:14 +0000

[Cc'ed to the list since it is relevant discussion]

On Sunday 07 September 2003 14:20, Curtis wrote:
> Marc,
>     I just read the draft, and I have a question about the use of MX
> records for validation. Would it not be easier to just verify that the
> address record for the server exists and is valid? If each server is to
> declare its name, and the IP address is determined, then it would be
> possibly to simply do a forward lookup on the address, then compare the
> returned IP address with the determined IP address. In this situation the
> MTA would also need to compare the server's name with the origin domain of
> the email to make sure it matches.  This would avoid the issue of systems
> that use multiple MX records on the same priority, as well as eliminate the
> need for the sub-domain MX records that are mentioned.

Well, I'm not sure what issue you mean about multiple MX, but the decision to 
not use A (or AAAA) records is, IMO, critical:

For instance, the address that I present to the world right now is 
mtl-hse-ppp168299.qc.sympatico.ca.  This will resolve correctly both way.  
Enabling me to use the A record would allow me to claim authority over that 
domain name, which might be true but completely pointless.  If you match only 
the second level name then I would be able to claim authority over 
sympatico.ca which is obviously a Bad Thing.

Using MX record, you introduce one extra layer of verification: you can only 
claim authority over domains whose zone file you control.  It means (a) 
spammers cannot claim authority over a domain they do not own [short of 
compromizing their DNS or mail servers, in which case they could pretty much 
do anything they want anyways] and (b) the barrier to creating throwaway 
accounts for spamming has increased a great deal  (I.e., you need a new 
domain, *and* control over the zone file which the hosters [wisely] almost 
never give).

Technically, looking up the MX record is almost exactly equivalent to looking 
an A record; you just ask for a different RR.  One-to-many mappings are more 
frequent but robust implementations must already be able to handle multiple A 
records anyways.

-- Marc A. Pelletier