Re: Additional Changes for RFC2821 MAIL FROM checking

> Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com> wrote:
> > > 1) Amount of change in software components (MDA, MTA, MUA, DNS servers,
> > >    DNS resolvers).
> > MAIL FROM checking would require changes to support some form of
> > rewriting or aliasing if the message is forwarded with the same
> > bounce address,
--John Leslie <john(_at_)jlc(_dot_)net> wrote:
>    This is not actually true, except in the so-called "general case",
> which is actually fairly rare. (Isn't English wonderful! ;^)
>
>    The actually common cases of forwarding follow an "outbound" path,
> where emails travel from MTA to MTA for policy reasons until one of
> them actually forwards based on MX records; then follow an "inbound"
> path, where emails travel from MTA to MTA for firewalling reasons or
> for "backup MX" purposes.
>
>    This structure need not ever rewrite bounce addresses.

I really like the idea of MAIL FROM checking.  Yakov points out some 
concerns and John points out some good solutions.
In general, most legitimate email will be
- handled by agents for the sender,
- handed off at a well-known MX point, then
- handled by agents for the receiver.

If we want to check MAIL FROM at any point in the chain, we definitely need 
a policy statement from the sender saying "here are the valid sending 
MTAs".  (Either a list or lookup table or a policy statement like "a mx 
ptr" would work here, choose one).


>    The sending domain simply includes all "outbound" MTAs in the set
> of known-good MTAs; and the receiving domain simply ensures that the
> authorization DNS records are checked on its first MTA, while the
> rest of their MTAs trust what comes from that first MTA. Thus the
> bounce address need never change.
>
>    (Backup MX might even become useful again, under that scenario.)

Agreed.  It would be *cool* if receivers could have a way to publish 
*their* list of incoming servers, for internal use only.  This would 
include the MX for the receiver's address, and possibly any other relays 
that handle the messages inbound.  I say "would be cool" because it's not a 
hard and fast requirement for MAIL FROM checking to work - we can handwave 
this and say "Don't check MAIL FROM if you're talking to a 'trusted' 
machine in your same domain."  (For example, you turn on MAIL FROM checks 
and hand it a list of trusted servers who are agents for the receiver.) 
The only reason I mention this is that the list of "other trusted 
receiver-side servers" could be published in much the same way that the 
sending servers are published.  I'm thinking here of drop-in MAIL FROM 
solutions that don't need you to feed it a whitelist, they can just read it 
from your own DNS just like the sender records.

>    If someone actually wants to set up an "open" relay, not listed
> for the sending domain, there's nothing to stop them from munging
> the bounce address so that it comes back to them (which would pass
> any MARID checks), and is then forwarded to the original bounce.

I *do* think third-party forwarding is a difficult problem, and it deserves 
some careful thought.  We don't have to *SOLVE* it in the MARID MAIL FROM 
proposal, but we can point out to third-party forwarders that multiple such 
solutions exist.
1. Rewriting MAIL FROM, using SRS or similar  (large forwarding houses will 
like this)
2. Some other bounce handling, such as an alternate contact for the 
receiver
3. Just tell receivers to white-list your relay  (small operations may 
prefer this)

>    I see no reason for us to worry about any rewriting scheme.
> Any changes one would require are local to the MTA that does the
> rewriting.

I agree with John that we don't have to completely solve all the 
ramifications...  It's a difficult problem, but if we're fairly confident 
there IS at least one solution, we don't have to provide the solution 
ourselves.  It's entirely possible that someone else will come along with a 
really creative solution that none of us thought of.  Read over RFC2476 -- 
they do something similar -- they specify that local users at the MSA must 
be authenticated and then list several possibilities (smtp auth, trusted ip 
range, pop-before-smtp, and "other" DIY solution)

>    I don't believe that's necessary at all (for RFC2821 MAIL FROM
> checking, which is all I'm discussing). If you're talking the
> final receiving MUA, whether it chooses to parse headers is an
> entirely local decision, not at all necessary to accomplish
> verification of bounce addresses.
>
>    (Which is not to deny that people may write MUA filtering
> programs which do all that: but they are fundamentally beyond our
> scope. We certainly will not recommend that as the appropriate
> way to do MARID checking.)

I'm going to agree here also, but again with a slightly different spin.  If 
we say how MARID MAIL FROM checking is intended to work, we are still 
leaving the door open for other implementations.  For example, SpamAssassin 
can learn the name of your usual Received: server and do MARID checking 
based on the information there.  We don't have to solve the "how" to just 
say it's allowed.

>    I expect we will recommend that the sending domain's MSA perform
> checking and rewriting as recommended by RFC2476, to ensure that
> what it passes on as the RFC2821 MAIL FROM will in fact pass the
> expected MARID checks. This burden does not seem heavy, but of
> course the originating MUA could easily be configured to always
> send a known-authorized MAIL FROM to its MSA.

Yay for leaning on existing RFCs :)



> > There is also an issue with the need to change configuration
> > whenever an MTA changes IPs.
>    The same as for HELO-only checking, IMHO.

Actually there are some methods where this is built in, like "a mx ptr" 
provides a way to check MAIL FROM without actually giving a list of IPs.
I'm not married to this approach, but it's a tradeoff like anything else. 
If your receiving mailer is already checking MX records for the MAIL FROM 
domain and the rDNS of the peer, it has the info already to make an "a mx 
ptr" type of decision.  (In other words, SPF does this, so it's probably 
not too onerous, but again I'm not going to try to railroad this "policy 
statement" type of approach... just presented here as a counter-example to 
"need to change configuration whenever an MTA changes IPs.")



>    Greeting Card, newspaper and other "Send copy to friend" sites
> clearly SHOULD supply their own RFC2821 MAIL FROM. If not, rejection
> at the first receiving MTA is the appropriate result.
>
>    (In other words, I agree that if there are any remaining mailing-
> lists, greeting-card, send-copy-to-friend, or similar sites, full
> MARID checking would break them; and I think that's a good thing.)

An alternate spin on this is, it's never polite to just break someone 
else's service, but the changes are easy, and I think most sites will get 
on board.  Having to change the greeting card or "Tell a friend" service to 
use their own domain for bounces is a small price to pay to get MAIL FROM 
control and be able to read each bounce again.

> > Mobile users will not be able to send email unless they used an MSA
> > they have access to or their own domain while listing the IP
> > dynamically in DNS.
>    This is not quite right. Mobile users which are denied access to
> a MSA which will supply an authorized RFC2821 bounce address will
> probably be prevented from sending email to most receiving domains.
> Barring bureaucratic stupidity, market forces should fix that
> quickly.

Another example of a difficult problem that already has a handful of 
solutions.  I agree that we don't have to solve it for EVERY user.
It's probably enough to say:

MARID MAIL FROM checking might force some mobile users to change their 
settings a bit.  A common solution is to use SMTP AUTH to connect to your 
usual mail server, but there are other solutions too.
(Remember, RFC2476 already states a requirement that "outgoing relays 
should be able to vouch for the return path used, or substitute their own 
known-valid return path" and that RFC is 5+ years standing.  RFC2476 also 
provides a recommended solution: keep the From: address the same but update 
Sender: and MAIL FROM/Return-Path...  This could be our 2nd solution -- 
send with From: <work address> but MAIL FROM/Sender: <home address> and 
bounces go to your home.)


--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>