Subject: Re: [Asrg] 6. Proposals: LMAP - Forwarding Comment and Recommended Changes

From: "Jon Kyme" <[email-masked]>
Date: Mon, 15 Dec 2003 11:11:58 +0000

> First of all, there are two separate but not disjoint cases of forwarding
> that could occur in a messages transmission path:
> 1. A Message Originator relays its mail through a third party host
>2. A Message Recipient has mail delivered to a designated host, which 
> then passes it along.
[snip] 

> The first case is much trickier. It means that a third party to a 
> commmunication must be trusted. For example, all of my outgoing mail,
> with
> the zemos.net domain, is relayed through smtp.comcast.net because of
> broken
> mail policies at other domains (read: AOL). This 'smart host' is
> effectively
> an open relay for all Comcast customers. If I don't add it to LMAP,
> messages
> relayed through it would rightfully be rejected by the recipient MTA, 
> because they don't originate from an LMAP designated MTA. However, if I
> do
> add it, any Comcast customer would be able to forge the zemos.net domain 
> without trouble.
> 

I take it that the policy that you're referring to as broken is the policy
of not taking mail from dial-up IPs ?

> My recommendation for how this case should be handled is as follows. This
> scenario should be added in some form to LMAP:
> 1. lmap-mta is authorized to send mail for sender.com
> 2. lmap-mta is connected to the internet via a random ISP, isp.com
> 3. lmap-mta is forced to relay mail through smtp.isp.com (outside policy,
> port 25 block, MTA-Mark)
> 4. smtp.isp.com is authorized to send mail for isp.com
> 5. lmap-mta connects to smtp.isp.com and transmits a message with a MAIL 
> FROM in sender.com.
> 6. smtp.isp.com verifies that lmap-mta is LMAP-authorized by sender.com
> 7. smtp.isp.com accepts the message
> 8. smtp.isp.com rewrites the sender envelope to encode the original 
> return-path in an address at isp.com
> 9. smtp.isp.com connects to mx.recipient.com and transmits the message
> 10. mx.recipient.com verifies that smtp.isp.com is LMAP-authorized by
> isp.com
> 11. mx.recipient.com accepts the message, but is later forced to generate
> a
> bounce notice about it.
> 12. mx.recipient.com sends the bounce message to the isp.com return-path
> 13. isp.com's MX sees the specially-encoded return-path and passes the 
> notification to the original return path.
> 14. The message originator @sender.com receives the bounce message.
> 
> The missing link in this scenario is the standardized encoding for the 
> return-path within a return-path. If this idea is already in use by some 
> commercial servers, I'd love to hear about it. If not, we need to come up
> with some appropriate design (some variation on VERP might work) and
> suggest
> it in the LMAP draft. There's no need to REQUIRE the use of a specific 
> format, because it only needs to be uniform within each ISP or relay, not
> Internet-wide.
> This makes LMAP a reasonable alternative to Yahoo's Domain Keys proposal.

I think you're right, to make this kind of relaying work nicely, something
along these lines would need to be provided. It makes the return-path the
same as the outward path. That symmetry is probably a Good Thing and might
be usefully provided for your second case (and others) also,
i.e. all intermediate MTA should perhaps have the ability to rewrite the
envelope from and decode for bounces.

Would it be useful to consider rfc3461 ENVID in this context?
I don't know how wide support for this is (is there any?).

--

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

---

From: Philip Miller <[email-masked]>
Date: Mon, 15 Dec 2003 08:42:58 -0500

Jon Kyme wrote:
>> with the zemos.net domain, is relayed through smtp.comcast.net because
>> of broken mail policies at other domains (read: AOL). This 'smart host'
>> is effectively an open relay for all Comcast customers. If I don't add
>> it to LMAP, messages relayed through it would rightfully be rejected by
>> the recipient MTA, because they don't originate from an LMAP designated
>> MTA. However, if I do add it, any Comcast customer would be able to
>> forge the zemos.net domain without trouble.
> 

Basically, yes. There's a page located at 
<http://postmaster.info.aol.com/guidelines/standards.html> that details 
their anti-spam policies. For all I know, my server my run afoul of more 
than one.

>> return-path within a return-path. If this idea is already in use by
>> some commercial servers, I'd love to hear about it. If not, we need to
>> come up with some appropriate design (some variation on VERP might
>> work) and suggest it in the LMAP draft. There's no need to REQUIRE the
>> use of a specific format, because it only needs to be uniform within
>> each ISP or relay, not Internet-wide. This makes LMAP a reasonable
>> alternative to Yahoo's Domain Keys proposal.
> 

I'm not too familiar with this. I'll read it later today.

Philip Miller

---

From: Daniel Feenberg <[email-masked]>
Date: Mon, 15 Dec 2003 11:26:27 -0500 (EST)

> I'm not too familiar with this. I'll read it later today.

With respect to the question: Is there any support for ENVID?
Looking on google, it seems that many MTAs support it.

I found positive references to support for ENVID by:

    Sendmail (8.8+)         
    Courrier
    PMDF
    zmailer  
    MH 
    qmail

This last is significant, since qmail's VERP is a substitute for ENVID
proposed when DJB considered support for ENVID insufficiently widespread.
I found references to security holes in the ENVID support by:

    MS Exchange 
    Lotus Domino 

so they must support it, too. I did find a newsgroup posting from someone
saying that POSTFIX did not support ENVID - the only MTA I found such
information about.

Sendmail supports ENVID from the sendmail command line with the "-V"
option.

I haven't tested any of these, but note that ENVID is documented in
rfc1891, so it is not a new feature. The update in 3461 only fixes the
character set and size.

Daniel Feenberg

---

From: "Jon Kyme" <[email-masked]>
Date: Mon, 15 Dec 2003 16:54:01 +0000

> saying that POSTFIX did not support ENVID - the only MTA I found such

I think I'm right to say that exim doesn't do DSN at all.
I'm sure that some kind of verp might be required as a fallback, but it
occurred to me that this is the kind of thing that ENVID would be well
suited for... perhaps.

--