Subject: Re: Mail-Transmitter RR

From: Derek Atkins <[email-masked]>
Date: 01 Jun 2002 22:40:29 -0400

Ted Lemon <[email-masked]> writes:

> > Agreed.  I send mail from my laptop, which travels with me all over
> > the place, but my From address is elsewhere.  How is my home address
> > supposed to know what IP address I'm using at any particular point in
> > time?
> 
> You contact an SMTP server for your domain over SSL, authenticate yourself,
>   and drop the main on that server, which can then safely forward it.

Who is "you" in this case?  My MUA?  My MTA?  I'm currently running
sendmail on my laptop.  My MUA just passes the mail on to there, and
it gets forwarded appropriately.  This is a nice feature because there
are many times when I have better connectivity between my laptop and
my recipient than I would going from laptop->home->recipient.  Are you
saying that instead of distributing the load of mail I now have to
centralize mail delivery just because people are abusing the
distributed nature?

> So don't use MAIL-FROM if it doesn't work for you.   I think this is
> an unlikely problem, though.   I use a remote mail drop for every
> email message I send, and it has never caused me any inconvenience.

Perhaps your definition of inconvenience and mine are different?  But
consider this: if not everyone is doing it, then what's the point?  If
it's not a ubiquitous solution, then it's not going to solve the spam
problem.  All it will do is prevent spammers from forging a valid
email address to recipients that have agreements with that individual.

I was hit by this today... Some spammer used my address to send out a
bunch of messages, and I was lucky enough to get all the bounces into
my inbox.  I certainly did not know any of the recipients whose mail
bounced back to me.  So, how would this have helped me (or them) in
this case, especially if you're telling me not to use it?

> This proposal doesn't solve the spam problem, but it _does_ make it
> harder for spammers to get away with forging email addresses, which
> would be a big improvement.   What's more, it does not require that
> you agree to it.   It only requires that people who are victims of
> forgery agree to it, and that people who care about forgery agree to
> it.   So if you don't like it, don'
> t do it.

See, I'm not convinced it will make it much more difficult unless it's
a upqiwuitous deployment, and I believe that the functionality that is
destroyed by deploying this technology is not worth the perceived
benefit.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "Eric A. Hall" <[email-masked]>
Date: Sat, 01 Jun 2002 22:42:39 -0500

> email address to recipients that have agreements with that individual.

This is the crux of *an* argument, but not *the* argument, IMO.

 Negative: The spammers will stop using hotmail.com, will scurry
    away from the bright light, and will start forging mail from
    somebody else's domain. Zero-sum gain for us, the recipients
    of spam.

 Negative: We lose a valuable filter (DENY HOTMAIL.COM).

 Positive: Hotmail has control over it's domain. I can accept
    mail from them again.

 Positive: Nobody will send forgeries from *my* domain. They
    will not announce winners for contests I've never held. They
    will not spread trojans *from other networks* claiming to be
    coming from me.

 Positive: Nobody will send forgeries from *your* domain, if you
    choose to opt-in to the self-ACL scheme.

 Positive: I have another weighting filter for my post-transfer
    filtering scheme, whereby non-participants are slightly less
    credible, while participants get whitelisted automatically.

There is only one negative that hurts. The other negative is a neutral.

There are certainly other valid issues with this approach. It can be very
difficult for ultra-mobile users to participate, for example. But it is
also elective, and only applies to the mail domain under your control.

I just can't see anything wrong with letting people say "only accept mail
from me if it comes from this network".

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Mathias Koerber <[email-masked]>
Date: Sun, 02 Jun 2002 12:11:05 +0800

> centralize mail delivery just because people are abusing the

I wouldn;t say 'have to'. If you have other ,ethods of authenticating your
mail (ie pgp etc), the receiving MTAs should be free to ignore the
MAIL-FROM RR if they can authenticate you that way.

The problem with that approach is that they would have to receive the
complete email first, *and* that they'd need the ability to do 
authentication
which usually now is done in the MUA.
On the otherhand, this approach is *voluntary*, and no-one forces you to
publish your MAIL-FROM MX ifyoudon't want to use it.

> email address to recipients that have agreements with that individual.

No. The beuaty of thes approach is that there is no specific agreement
between each pair of potential senders and recipients necessary.
A recipeint decides whether s/he wants to use this method of MAIL-FROM
is such an RR exists for the sender, and the sender simply published
it if they want their addresses protected from abuse (at least to those
sides that actually check for it).

> this case, especially if you're telling me not to use it?

You can't have it both ways. It will help you only if you use it, but
that means using list of predefined MX hosts. There are tradeoffs.
If you really want, you can list your laptop in the MAIL-FROM MX
list and use DDNS to update its IP address before sending mail.
There should not be any problems with the mail hanging around and
someone checking the MX after you lose that IP address, as it is the first
MTA after your sender that will have to perform this check.

> destroyed by deploying this technology is not worth the perceived

I don's see any functionality being destroyed. You will have to make a 
choice
which is more important to you, fast, shortest-hop delivery to the nearest
recipient MTAs or the protection of your address(es).

mk

---

From: "Andy W. Barclay" <[email-masked]>
Date: Sun, 02 Jun 2002 05:04:24 -0700

Hi Derek,
Actually, I do advocate that you send all mail from your laptop
through your home machine, then on to the final recipient.

This is no different from the way 90% of the population of the Internet 
does things now. Most people don't run sendmail on their laptop.
In fact, I am currently connected to the net via a dsl connection
to sympatico in Canada right now. The sympatico firewalls block
out-bound SMTP, so you are supposed to use their SMTP servers. (I tunnel
smtp to my home server via ssh). This would adversely affect your 
ability to use your laptop as a relay. Lastly, the mail-abuse.com people 
define a method of blocking mail which comes from "dial-up" addresses.

I think that your solution of using your laptop will slowly become
less and less reliable, and I think that both Paul's proposal and
David Green's proposal have merit. (In case anyone is interested,
several of my compatriots are using spamassassin to kill spam,
and its working very well for them (99.5% success rate, .4% false
positives)

-- 
Regards,
Andy W. Barclay.        [email-masked]
fax  (781) 823-8276
Always a UNIX Evangelist (and sometimes a system and network architect)

The truth of a proposition has nothing to do with its
credibility. And Vice-Versa.

---

From: David Green <[email-masked]>
Date: Sun, 2 Jun 2002 11:55:40 -0400 (EDT)

On Sun, 2 Jun 2002, Mathias Koerber wrote:
> choice which is more important to you, fast, shortest-hop delivery to
> the nearest recipient MTAs or the protection of your address(es).

Nicely put :) UCE is THE killing factor of using email today. Checking my 
email is a love/hate relationship. At least I have an excellent filter on 
it, but a dozen spams still get through every day. What I don't care about 
is how long it takes me to send one via my isdn (once queued on the 
server, who cares...)

Paul, your proposal is thought out much better than mine. However, I don't 
agree with overloading the MX RR to make this happen. I think that using 
an SRV RR would be a better choice, as this might lead to 
domain-authentication of other services in the future:

    out.smtp.tcp SRV 0 0 smtpsender.asdf.com
    out.http.tcp SRV 0 0 httpproxy.asdf.com

Perhaps even put source port-numbers in there as well...

David Green

---

From: Måns Nilsson <[email-masked]>
Date: Sun, 02 Jun 2002 18:38:29 +0200

--On Sunday, June 02, 2002 05:04:24 -0700 "Andy W. Barclay"
<[email-masked]> wrote:

> does things now. 

Perhaps 90% of the people on the Internet use Windows. Are you suggesting
we  should force everyone to use Windows just because 90% of the people on
the Internet do so? 

The proposal(s) break(s) e-mail in fundamental and worrying ways, and make
the probability of e-mail delivery in adverse conditions much lower (think
backhoe incident on main internet connectivity, trigging the use of dialup
for backup connectivity, and nobody remembering to add that netblock to the
good, allowed ones).

Us moderately and above clued people should not destroy the "survive-all"
capabilities of the Internet. There are others doing that much better. 

This is a bad suggestion, and it needs to be stopped. 

/Måns, who has a sendmail running on his laptop. 
-- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC  MN1334-RIPE

We're sysadmins. To us, data is a protocol-overhead.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 02 Jun 2002 09:50:07 -0700

> From: David Green <[email-masked]>
> 
> Paul, your proposal is thought out much better than mine. However, I
> don't agree with overloading the MX RR to make this happen. I think
> that using an SRV RR would be a better choice, as this might lead to
> domain authentication of other services in the future: [...]

We would be overloading SRV just as much as the current proposal does MX.
More to the point, the patch to sendmail to implement MAIL-FROM is less
than 100 lines if MX is used.  Given the number of disparite code bases
out there, ease of implementation will translate directly to the growth
of an installed base.

> Perhaps even put source port-numbers in there as well...

Unless there's something _needed_ that SRV provides (load balancing,
port numbers) I think it would be better to avoid it.  And I speak as
an author of the SRV RR when I say that in this case.

> From: Derek Atkins <[email-masked]>
> 
> The problem with this proposal is that only the first-hop can actually
> check the message.  All the spammer needs to do is find an open relay
> that does not implement the "remove the Authorized-by header" and they
> are home free, and even this MAIL-FROM technique wont help.
> Considering that spammers are already utilizing open relays, this
> isn't really a big change for them.  So even if people opt-in to this
> proposal, I don't see it actually helping.

I've strengthened the wording on [MAILFROM 2.2] which now reads:

   2.2. Second-stage relays such as ISP mail servers are often used and can
   be described by adding as many relays as necessary to the MAIL-FROM MX
   RRset.  In our example, if ISC sometimes used UUNET for outbound mail
   services, the DNS data describing this relationship might be as follows:

      $ORIGIN isc.org.
      MAIL-FROM MX 0 rc
                MX 0 rc1
                MX 0 uunet.uu.net.

   Let it be noted that a domain owner's power to repudiate forged e-mail
   is only as strong as the security policy of its registered inbound and
   outbound mail relays, and that if such a relay is (for example) open to
   third party relay, then no value will be added by registering a domain
   MAIL-FROM MX containing that relay, and no inbound MAIL-FROM checking
   will be possible on final delivery relays for a domain @ MX containing
   that relay.  Multistage relays (both inbound and outbound) are a
   breeding ground for anonymity unless they are very carefully configured.

I think that there's a LOT of help to be had from this, amongst anonymous
but cooperating domain owners and relay owners.  I'm not pushing this as
the one true way to stop all spam for all time, because I don't think there
is any such.  It's an optional, low-impact way to protect folks like hotmail
from widespread forgery.  Probably it won't slow spam down one whit, but it
will reduce the overall injury from spam.

> Unfortunately second-hop mail proxies can't perform the same check on
> the MAIL-FROM, because all they have is the Received-By headers.  In
> fact, how is an MTA supposed to know whether it is the first-hop or not?

For the record, I'm against header munging and against Received: parsing by
MTA's.  Both are layering violations, though of different kinds.  The right
solution is to know and trust the configuration of your @ MX relays and also,
if you choose to use MAIL-FROM, of your MAIL-FROM MX relays.  The text above
strengthens the case for this requirement, which is in fact already present
in the existing mail system in any case.

> Also, without DNSsec the spammer could try DNS forging attacks as well.

OK, so I hate it when I have to quote something you've already seen, but:

   4 - Security Considerations

   In the continuing absence of widely deployed security for DNS, this
   proposal effectively places an access control list for forged
   source/return information in a place where it can be attacked.  However,
   it must be noted that the current senders of forged unwanted bulk e-mail
   are typically not technologically capable of attacking the DNS to insert
   forged MAIL-FROM data.

You can call the above a cop-out if you want, but since we're moving a
problem from a solutionless arena (end-to-end MTA authentication) to a
solutionful arena (deploy DNSSEC) I consider the movement to be "progress."

> From: David Green <[email-masked]>
> 
> > The problem with this proposal is that only the first-hop can actually
> > check the message.  All the spammer needs to do is find an open relay
> > that does not implement the "remove the Authorized-by header" and they
> > are home free, and even this MAIL-FROM technique wont help.
> 
> There should only be a single hop between separate logical entities on the 
> public Internet. The final sending host of the sending entity would need 
> to be marked as an authorized mail transmitter for the domain. Inside of 
> each entity, they can set up any rules they like.

If a cooperating set of MX's (inbound @ or outbound MAIL-FROM or both) wants
to implement such a scheme then it falls under the general category of
"knowing and trusting the configs of your domain's MX relays".  It's out of
scope for this proposal, but implementation experience, open source patches,
and a BCP would go a long way toward advancing this particular form of trust.

---

From: "Al Costanzo" <[email-masked]>
Date: Sun, 2 Jun 2002 12:36:11 -0400

Sorry,

IMHO it breaks nothing. It is not a required RR it is a suggested one. If
you cant SPAM in your mailbox fine, for those of us who do not it is an
excellent idea.

-al

---

From: David Green <[email-masked]>
Date: Sun, 2 Jun 2002 13:21:58 -0400 (EDT)

> for backup connectivity, and nobody remembering to add that netblock to the

My idea doesn't break or change anything. It just allows endpoint SMTP 
servers to add a header to mail, which may or may not be examined by 
end-user MUAs.

David Green

---

From: Randy Bush <[email-masked]>
Date: Sun, 02 Jun 2002 10:34:04 -0700

thanks, måns.  indeed, many of us don't run windoze and don't think
colonial mail routing.

the problem is that this is really a side-eddy to the spam maelstrom.
this discussion is about all sorts of hacks to allow one to force the
source of the mail to be honest about whence it comes.  while this is
nice, it is indirect and merely gives you a slight leg up on chasing
ten thousand slimeballs.  it is like trying to use source spoofing
prevention to stop ddos attacks, a useful tool but not a real solution
by a long shot.

so how much should we mangle the net (prevent direct delivery of mail
from laptops etc) for a partial approach to being able to assign
responsibility to spammers who will ignore responsibility anyway?

randy

---

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 02 Jun 2002 12:49:16 -0500

> We would be overloading SRV just as much as the current proposal does MX.

Moreover, it overloads SRV in a bizarro way, defining a client rather than
a server. Avoid mangling the interpretation of SRV please, adoption is
slow enough as it is.

> than 100 lines if MX is used.

MX is not flexible enough by itself. At the very least, you also need a
way to map PTR space to the sender domain such that EG anybody with a PTR
of ehsco.com. is hereby authorized by me to send mail from @ehsco.com.[1]
Also, having the ability to define specific hosts lets mobile users setup
user.domain.dom mail domains on a dynamic basis, so you need a way to map
in A/AAAA RRs as well.

I think that all of the above illustrates why you really need a new RR
using codes (as in the mail I forwarded earlier), rather using a static
owner name.

[1] Two subordinate issues with PTRs. First of all, there must be a
mandatory forward-path verification of the PTR data, otherwise any idiot
can add a PTR to their in-addr space and spoof me, which solves nothing.
Second, remember that this option would only be definable by the owner of
the domain, so it couldn't be used as a casual attack even when the
forward lookups were not used.

---

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 02 Jun 2002 13:04:32 -0500

> responsibility to spammers who will ignore responsibility anyway?

I would suggest that the mail network is already mangled. This is a way to
clean up my own little corner of the network with no impact to you. You
would be under no obligation to do this for your own network, or to query
my network. You can ignore it, just as you ignore any other scheme you do
not want to participate with.

The silver bullet exists, but in the form of a new message format and
transfer protocol. Goooood luck with that one.

Leathering through RBLs, reverse-path verification, keyword filters,
distributed checksums, are all things that people use now. An authorized
sender RR/owner/whatever is just another tool in the toolbelt. This one at
least has the interesting property that it is voluntary, meaning that when
it exists, it has more credibility than third-party mechanisms.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 02 Jun 2002 11:33:11 -0700

there are three replies contained here, plus a big finish.

--------

> From: Randy Bush <[email-masked]>
> 

that's all spam-related and it's from the perspective of the recipient.

this proposal is not about spam, and the primary expected beneficiaries
are domain owners who presently have no power to repudiate forgeries of
their intellectual property.

at the moment, the "[email-masked]" mailbox is full beyond overflow,
and 98% or more of the traffic is about incidents which hotmail's own
customers and servers had nothing to do with.  this is a DDoS against
an isp abuse/support desk which protects the flow of the other 2%.

> responsibility to spammers who will ignore responsibility anyway?

my laptop will still deliver mail directly, either because i'll send it
from a domain with no MAIL-FROM, or because i'll use RFC2136 dynamic
updates on my own A RR (note: this is not DHCP or PTR related!) when i
travel.

--------

> From: Alan Barrett <[email-masked]>
> 
> >       $ORIGIN isc.org.
> >       MAIL-FROM MX 0 rc
> >                 MX 0 rc1
> 
> I think that the magic label should begin with an underscore
> (e.g. "_MAIL-FROM"), for the same reasons that we use "_tcp" rather
> than just "tcp" as a label for SRV records.

i thought of that, but my concern is the number of extant getmxrr() 
library implementations who "just know" that a leading _ is invalid.
randy and others would be quick to point out that such implementations
are broken, but fixing them is going to add more inertia to the equation
and it's a battle i'd rather postpone.  MAIL-FROM is sufficiently unique
(i grepped a few gig of mail logs and found no occurances) that it ought
not have any collisions.

i still remember the debate over the _ in _tcp and _udp with the SRV RR,
and as an author of SRV i'd like to not tread that ground again so soon.

--------

> From: "Eric A. Hall" <[email-masked]>
> 

that's a strictly local configuration issue, as everything PTR-related
must be and in every case will be.

> user.domain.dom mail domains on a dynamic basis, so you need a way to map

see my comments above regarding my own laptop's choices in this scenario.

> using codes (as in the mail I forwarded earlier), rather using a static

i think this debate illustrates why the ietf is so broken -- anyone can say
no and there's nobody anywhere who can definitively say yes (witness A6/DNAME
in IPv6, and RSA/DSA/RSA/DSA/etc in DNSSEC).

my big plan is to get as many good ideas as possible from this community
and then market this proposal in "ietf bypass mode".  it's completely
optional and specifies no wire protocol changes, and when it does
finally come through the ietf it will be as a successful and widespread
method which has become worthy of its own BCP.

you are welcome to roll out a custom RR in parallel.  BIND will support it,
and i will adopt it on my own servers, and if it happens to work, we'll all
be happier for it.  but i rather expect that you'll be shot in the back every
day for three years, told to use IPsec, told to use SSL, told to use PGP,
told to use S/MIME, told you're approved, told you're not, and so on.

--------

i keep thinking of how the world would be different if i'd helped jim miller
get this proposal written and circulated back in 1998 when he thought of it.

---

From: "Eric A. Hall" <[email-masked]>
Date: Sun, 02 Jun 2002 15:30:01 -0500

> their intellectual property.

Bingo. It's about me being the master of my own freaking domain.

As to your plan, I think there is certainly merit to doing it as a private
agreement type of thing first. We can see how well it works without
burning cycles on the IETF (my own suspicion is that it will be popular
with small networks, but unpopular with hotmail et al). If it works, we'll
have better understanding for future efforts, and without having to worry
about collisions. Not to mention the "running code" value.

Having said all of that, I truly despise the MAIL-FROM label.

---

From: "Al Costanzo" <[email-masked]>
Date: Sun, 2 Jun 2002 16:54:11 -0400

If the IETF system is not completely broken as I suspect it is.  I do not
see why the draft could not be written, given to the RFC Editor to publish
as Experimental and then move it to a working group to get it onto standards
track at a later date.

If my memory serves me properly (and I am getting on in years now), this is
what Experimental was all about.

-Al

---

From: Paul Vixie <[email-masked]>
Date: Sun, 02 Jun 2002 14:47:10 -0700

let's not all start worrying about the wrong things here.

> > As to your plan, I think there is certainly merit to doing it as a
> > private agreement type of thing first. We can see how well it works
> > without burning cycles on the IETF (my own suspicion is that it will
> > be popular with small networks, but unpopular with hotmail et
> > al). If it works, we'll have better understanding for future
> > efforts, and without having to worry about collisions. Not to
> > mention the "running code" value.

> If the IETF system is not completely broken as I suspect it is.  I do
> not see why the draft could not be written, given to the RFC Editor to
> publish as Experimental and then move it to a working group to get it
> onto standards track at a later date.
> 
> If my memory serves me properly (and I am getting on in years now),
> this is what Experimental was all about.

two things.  first, experimental means that the people who have ietf
secret decoder rings weren't properly involved and so they now wish your
protocol had never existed.  SRV is an example, even though win2k and
kerberos use it in production and have wide deployment bases.

second, getting an RFC number can in some cases help with deployment
even if the status is experimental, but this is not one of those cases.
it was nec'y with SRV because the behaviour wasn't going to be optional,
and interoperability of wire formatting was a requirement.

once i'm satisfied that every technical contribution has been made (short
of "this needs its own RR type and wire format") and considered and that
the proposal isn't just plain bad, i'll submit it to the rfc editor as
experimental, and then in parallel i will market it on my own.  years
will go by during which the ietf will do nothing, except perhaps launch
its own deeper effort while rejecting the experimental rfc on the grounds
that it's an end run around the standards process.  later, we'll all have
forgotten about this.  but if it succeeds anyway, then i will resubmit it
to the ietf as a BCP, since by "success" that's what i'll mean.

i hope this doesn't come across as bitter.  several people have tried to
give me my very own ietf secret decoder ring over the years, but though i
have tried, i mostly can't figure out how it's supposed to work.  (all
real progress is either decoder-ring-friendly like IXFR/NOTIFY/UPDATE,
or it's decoder-ring-unfriendly like IMAP and SRV and ICP and HTCP.)

in case my own preferences are unclear, i killed BIND's UID and GID RRtypes
as well as mike schwartz's pre-standard dynamic update support, even though
a whole lot of people were using them, and i did it because things on the
wire have to be, in my way of looking at things, standardized.  MAIL-FROM
adds nothing to any wire format, so i'm willing to take a BCP path to it.

---

From: Allan Liska <[email-masked]>
Date: Sun, 2 Jun 2002 21:53:27 -0400

Hello,

Sunday, June 02, 2002, 12:50:07 PM, Paul wrote:

PV> I've strengthened the wording on [MAILFROM 2.2] which now reads:

PV>    2.2. Second-stage relays such as ISP mail servers are often used and can
PV>    be described by adding as many relays as necessary to the MAIL-FROM MX
PV>    RRset.  In our example, if ISC sometimes used UUNET for outbound mail
PV>    services, the DNS data describing this relationship might be as follows:

PV>       $ORIGIN isc.org.
PV>       MAIL-FROM MX 0 rc
PV>                 MX 0 rc1
PV>                 MX 0 uunet.uu.net.

PV>    Let it be noted that a domain owner's power to repudiate forged e-mail
PV>    is only as strong as the security policy of its registered inbound and
PV>    outbound mail relays, and that if such a relay is (for example) open to
PV>    third party relay, then no value will be added by registering a domain
PV>    MAIL-FROM MX containing that relay, and no inbound MAIL-FROM checking
PV>    will be possible on final delivery relays for a domain @ MX containing
PV>    that relay.  Multistage relays (both inbound and outbound) are a
PV>    breeding ground for anonymity unless they are very carefully configured.

PV> I think that there's a LOT of help to be had from this, amongst anonymous
PV> but cooperating domain owners and relay owners.  I'm not pushing this as
PV> the one true way to stop all spam for all time, because I don't think there
PV> is any such.  It's an optional, low-impact way to protect folks like hotmail
PV> from widespread forgery.  Probably it won't slow spam down one whit, but it
PV> will reduce the overall injury from spam.

There are a couple of problems I see with this.  One may not be a
problem at all, but here goes.

In the example you used above, and I am sure this is the same with
many large ISPs, UUNET's mail server, mail.uu.net, is actually 5
different machines:

mail.uu.net.            300     IN      A       199.171.54.106
mail.uu.net.            300     IN      A       199.171.54.122
mail.uu.net.            300     IN      A       199.171.54.245
mail.uu.net.            300     IN      A       199.171.54.246
mail.uu.net.            300     IN      A       199.171.54.98

If I add mail.uu.net as one my MAIL-FROM records, but the server
delivering the message is actually ashd1-2.relay.mail.uu.net, is that
message going to be rejected?  I don't imagine most DNS
"administrators" will know that mail.uu.net is really multiple
servers.

Secondly, doesn't this have the potential to be abused by mail
administrators that only kinda-sorta know what they are doing?  If a
mail administrator decides s/he doesn't want to accept mail from
anyone without a MAIL-FROM record, then it is no longer a voluntary
action.  Or is that not going to be part of the functionality?

I hope these made sense.

allan
-- 
allan
[email-masked]
http://www.allan.org

---

From: Paul Vixie <[email-masked]>
Date: Sun, 02 Jun 2002 19:28:38 -0700

> "administrators" will know that mail.uu.net is really multiple

i note that the server you mentioned...

	;; ANSWER SECTION:
	ashd1-2.relay.mail.uu.net.  59m34s IN A  199.171.54.246

...has the same address as one of the mail.uu.net A RR's.  so, the
published psuedocode...

      repudiated(mailfrom, ipsource) = {
           (lhs, rhs) = parse_addr(mailfrom);
           mxset = get_mx("MAIL-FROM" "." rhs);
           if (mxset == NULL)
                return FALSE;
           mxset += configured(perimeter_relays);
           foreach mx (mxset) {
                aset = get_a(mx.server);
                if (ipsource IN aset)
                     return FALSE;
           }
           return TRUE;
      }

...would indeed permit your mail to come from that host if all you
added to your own domain's MAIL-FROM MX RR was "mail.uu.net".  this
kind of address antialiasing can be a problem, as witnessed by the
PTR RR for this address...

	;; ANSWER SECTION:
	246.54.171.199.in-addr.arpa.  1H IN PTR  ashd1-2.relay.mail.uu.net.

...which can only point to one name even though two names are usable.
however, it's not a problem for the MAIL-FROM proposal as written.

> administrators that only kinda-sorta know what they are doing?

no moreso than DNS itself.  i just "tail"'d my daemon.log file and saw...

Jun  3 02:22:36 isrv3 named[184]: wrong ans. name \
	(. != 10.7.118.135.in-addr.arpa)
Jun  3 02:22:36 isrv3 named[184]: invalid RR type 'PTR' in authority section \
	(name = '10.7.118.135.in-addr.arpa') from [192.11.222.170].53
Jun  3 02:22:36 isrv3 named[184]: invalid RR type 'NS' in additional section \
	(name = '7.118.135.in-addr.arpa') from [192.11.222.170].53

...that even without this new-fangled MAIL-FROM business, either a sysadmin
or a protocol implementor (or most likely, both) are able to get the power
cord wrapped around both legs while trying to drill this hole.

> If a mail administrator decides s/he doesn't want to accept mail from
> action.  ...

internet communication is bilaterally consensual, or doesn't occur at all.
if a mail server operator doesn't want to accept mail from me because i
don't have a MAIL-FROM, then no power on earth can compel them otherwise.

---

From: David Green <[email-masked]>
Date: Sun, 2 Jun 2002 22:49:57 -0400 (EDT)

> "administrators" will know that mail.uu.net is really multiple

I really don't see any choice but to authorize by IP address rather than 
by hostname, not only for security reasons, but also to avoid a double 
query for each incoming mail; one is quite enough. I'm still trying to 
figure out how to handle an ISP that would like to designate a range of 
IPs as valid senders, or one that has a very large number of valid 
senders.

> action.  Or is that not going to be part of the functionality?

That would not be part of the functionality in my proposal, although I 
think it would be in Paul's. Any filtering would be the choice of the end 
user (assisted by their MUA). This choice was made to avoid the situation
that you have mentioned here.

David Green

---

From: Paul Vixie <[email-masked]>
Date: Sun, 02 Jun 2002 22:49:03 -0700

> query for each incoming mail; one is quite enough.

fortunately for all of us, two queries are rarely needed.  let's watch dig:

	;; ANSWER SECTION:
	uu.net.                 1H IN MX        10 external-mail-router.uu.net.

	;; AUTHORITY SECTION:
	uu.net.                 1H IN NS        auth00.ns.uu.net.
	uu.net.                 1H IN NS        auth60.ns.uu.net.
	uu.net.                 1H IN NS        auth200.ns.uu.net.
	uu.net.                 1H IN NS        auth210.ns.uu.net.

	;; ADDITIONAL SECTION:
	external-mail-router.uu.net.  5M IN A  198.5.241.38
	external-mail-router.uu.net.  5M IN A  198.5.241.40
	external-mail-router.uu.net.  5M IN A  198.5.241.39
	auth00.ns.uu.net.       1H IN A         198.6.1.65
	auth60.ns.uu.net.       1H IN A         198.6.1.181
	auth200.ns.uu.net.      1H IN A         195.129.12.82
	auth210.ns.uu.net.      1H IN A         195.129.12.74

by god, look at all those A RR's.  i guess we won't be needing a second
query, huh?  as for security reasons, i'm going to quote the pseudocode
from my proposal one more time, so you can see that addresses are indeed
used.  i know that it seems, from reading the rest of what's been written
on this thread, that i must be interested in parsing headers and in 
comparing hostnames.  but if you read the proposal itself you'll see that
i'm advocating no such thing.

for the record, i'm through with quoting excerpts from the proposal, and
any questions which could have been answered by reading all four short
pages of the document, will hereinafter be ignored by me.

---

From: Randy Bush <[email-masked]>
Date: Sun, 02 Jun 2002 23:16:23 -0700

> query, huh?

add sigs and stir <sigh>

randy

---

From: Paul Vixie <[email-masked]>
Date: Mon, 03 Jun 2002 13:22:12 -0700

> So do you have a patch to sendmail that implements this draft?   :')

i don't even have a sendmail source pool any more.  sorry.  i'll do postfix
and somebody else can do sendmail.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 3 Jun 2002 11:28:32 -0500

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]