IETF SMTP Working Group Proposal at smtpng.org

Mailman List Mirror (Read Only)
1

Brad Knowles <brad.knowles@skynet.be> writes:

> How does it break mailing-lists? If the list sets the envelope sender
> to <list-request@listserv.domain.com> creating a MAIL-FROM shouldn't
> be a problem.

  You may be surprised to discover this, but most mailing lists are
not proper mailing lists and are not managed with proper mailing list
management software. Most mailing lists are actually handled as
aliases, and therefore do not modify the envelope sender address.

> The only problem I can see is what to do about bounces
> (i.e. with a null envelope sender) - guess you could use header From
> instead maybe.

  Actually, this is one area that the paper addresses.

       repudiated(mailfrom, ipsource) = {
            (lhs, rhs) = parse_addr(mailfrom);
            // handle "MAIL FROM:<>" somehow
            mxset = get_mx("MAIL-FROM" "." rhs);
            if (mxset == NULL)
                 return nonrepudiated;
                 ^^^^^^^^^^^^^^^^^^^^

OK - but unconditionally permitting null-return paths means that
spammers can drive a coach and horses through the hole it leaves. :frowning:

Martin

2

mjc@cooper.org.uk (Martin Cooper) writes:

OK - but unconditionally permitting null-return paths means that
spammers can drive a coach and horses through the hole it leaves. :frowning:

that's how the proposal is optional. spammers who lie about their
source/return addresses using nonexistent domain names are not the
subject of http://www.vix.com/~vixie/mailfrom.txt; rather, i'm
trying to address the issue of spammers who lie about _existing_
source/return domain names.

3

Paul Vixie wrote:

mjc@cooper.org.uk (Martin Cooper) writes:

> OK - but unconditionally permitting null-return paths means that
> spammers can drive a coach and horses through the hole it
leaves. :frowning:

that's how the proposal is optional. spammers who lie about their
source/return addresses using nonexistent domain names are not the
subject of http://www.vix.com/~vixie/mailfrom.txt; rather, i'm
trying to address the issue of spammers who lie about _existing_
source/return domain names.

This indeed will fix a lot of problems, and force people to use their
"mail upstreams" mail-relays.
ISP's should actually block port 25 outgoing, or even better,
reroute/forward it to their own mail relay.
This will force people to use their upstreams email address though when
sending email outbound.
And this isn't always what someone wants. But because especially the big
U has many 'users' who simply
take a dailup account, spew spam to all kinds of taiwanese, chinese, etc
servers those 'users' aren't hard
to block out unfortunatly.

IMHO, Paul's idea is quite a good one, but all servers will need to be
upgraded, and all dns entries installed.
Unfortunatly that will take some time, installing a tool like
spamassasin/razor etc is much more effective
even though those tools won't stop spammers.

At least it will help a bit against one of the bigger internet
"problems".

Greets,
Jeroen

4

Given the number of providers who seem to think ingress and/or rfc1918
filtering shouldn't be done, what makes you think that "all servers"
will be upgraded to support THIS proposal?

(If you don't want to re-start the RFC1918 war, feel free to substitute ANY
OTHER thing that most people think is a Good Thing, but we've seen some
sizable minority not deploy for reasons they consider perfectly valid).

5

> IMHO, Paul's idea is quite a good one, but all servers will need to

be

> upgraded, and all dns entries installed.

Given the number of providers who seem to think ingress and/or rfc1918
filtering shouldn't be done, what makes you think that "all servers"
will be upgraded to support THIS proposal?

Read my sentence again, because I really won't see everybody install/use
it.
One can also simply see so by the problems related to the fact of
installing security updates.
Some 'companies' and individuals are simply too sleezy/lousy or whatever
to do it.
And thus open spam relays will be kept alive which is why there are
RBL's.

This will only help a bit, and tools like SpamAssasin/Razor will keep a
load of stuff of your servers.
But unfortunatly one will never be able to block it all.

(If you don't want to re-start the RFC1918 war, feel free to
substitute ANY OTHER thing that most people think is a Good Thing, but

we've

seen some sizable minority not deploy for reasons they consider
perfectly valid).

8<-----------
RESERVED="0.0.0.0/7 1.0.0.0/8 2.0.0.0/8 5.0.0.0/8 23.0.0.0/8 27.0.0.0/8
\
        31.0.0.0/8 72.0.0.0/5 96.0.0.0/3 \
        128.66.0.0/16 191.255.0.0/16 \
        197.0.0.0/8 201.0.0.0/8 224.0.0.0/3 240.0.0.0/8"
MISC="127.0.0.0/8 128.0.0.0/16 169.254.0.0/16"
RFC1918="10.0.0.0/8 172.16.0.0/12 192.168.0.0/16"

# Setup block against reserved, rfc1918 and other nets
for i in ${RESERVED} ${MISC} ${RFC1918}; do
        RULE -A INPUT -i ${IF} -s ${i} -j LDROP
        RULE -A OUTPUT -o ${IF} -d ${i} -j LDROP
done

---------->8
In the filtering language you want, and yes one sees a load of crap in
your logs...
There is a way of making people apply rules though:
depeer/disconnect/...
Unfortunatly one can't easily do that to a party far far away, thus one
blocks at their end (spamassasin/razor and IP based rules)..

Making it harder to get into your house is better than putting the doors
wide open...
Every bit helps...

Greets,
Jeroen

6

As a user, I pay my ISP to forward IP packets. If there happen to be TCP
segments in those packets, that's something between me and the person the
packet is addressed to, whether the destination port of those TCP segments
is 25 or something else.

As a network administrator, I don't want to filter applications. It burns
too much CPU time on my routers, it costs me too much time to maintain
those filters and it doesn't work anyway.

Application people should make their applications secure and not impose
restrictions on the network because they're too lazy to come up with a new
protocol once every two decades or so.

7

Read my sentence again, because I really won't see everybody install/use
it.
One can also simply see so by the problems related to the fact of
installing security updates.
Some 'companies' and individuals are simply too sleezy/lousy or whatever
to do it.
And thus open spam relays will be kept alive which is why there are
RBL's.

This will only help a bit, and tools like SpamAssasin/Razor will keep a
load of stuff of your servers.

Paul's proposal doesn't require battening down every mail server out
there either. The particularly useful aspect of this approach is that
clueful administrators of more visible mail servers can cut down on
being spoofed. This would also be specifically effective against Klez
and similar annoyances. It doesn't matter if the spammer/virus is
cooperating with the system or not. If the final destination contacts
the mailfrom callback server, and it says "This definitely isn't
legitimate" then even with a small adoption rate, there will still be a
significant decrease in cruft, and the mail system being spoofed has
something better to point at when they get flooded with complaints from
people who actually trust the <mail from> field. But then, all this is
fairly clear in the draft. I can't figure out why it hasn't been more
widely accepted as a Good Idea. The presumably appropriate topic for
discussion on this list is why a system such as this would be a problem
for network operators who choose not to implement such a callback
feature. So far the only objection I've seen is "It won't make any
difference" and that seems to be a flimsy argument. Please correct me
if I'm missing something.

Making it harder to get into your house is better than putting the doors
wide open...
Every bit helps...

Exactly.

-dvd

8

IIRC, the RFCs require that you accept mail from the null envelope sender. Yes, it does open a hole, but spammers have avoided using this address for a long time, for reasons I still don't understand.

9

ISP's should actually block port 25 outgoing, or even better,
reroute/forward it to their own mail relay.

  Agreed.

This will force people to use their upstreams email address though when
sending email outbound.

  Yup.

IMHO, Paul's idea is quite a good one, but all servers will need to be
upgraded, and all dns entries installed.

  I still think that it causes problems for mailing lists.

  Moreover, you need to know the complete outbound path for all e-mail, from soup to nuts, so that you can add all those machines to the list of known mail-from MX entries for your domain.

  I'm sorry, complete information like this just doesn't exist anymore. Knowledge like this did exist twenty or more years ago, back when there were only a few UUCP nodes. But even then, things quickly got to a point where people couldn't possibly know all possible paths between any two points, and people just listed their address from a small set of "well known" nodes.

Unfortunatly that will take some time, installing a tool like
spamassasin/razor etc is much more effective
even though those tools won't stop spammers.

  I disagree that it would stop spammers. Even if everything else worked, all it would require is that they get more creative in faking e-mail addresses. They just have to make sure that when the mail is delivered to you, it comes through a machine that is on the list of MXes for the mail-from entry for the domain. Put a simple wildcard MX in there (and nothing else), and it should match anything.

  Moreover, even if all servers on the Internet were secured in this manner and there were no open relays, it would also require perfect reverse DNS because the MXes are listed by name and not IP address -- that's assuming you do a reverse lookup on the IP address and require that the returned name is on the list.

  If you do a forward lookup (taking each of the listed MXes for mail-from and looking up their IP address), that would require that no one use DNS-based or geographical-based load-balancing, because then the forward lookup on the name might not match the IP address of the sending relay.

At least it will help a bit against one of the bigger internet
"problems".

  I agree with the overall IETF approach of implementing something and seeing if it works (as opposed to talking things to death), but this is a case where I fear that the proposed solution could only work in a perfect world, and even then it would have some serious problems.

10

David Van Duzer <dvanduzer@infidels.org> writes:

[...]

The presumably appropriate topic for discussion on this list is why
a system such as this would be a problem for network operators who
choose not to implement such a callback feature. So far the only
objection I've seen is "It won't make any difference" and that seems
to be a flimsy argument. Please correct me if I'm missing
something.

The problems with it are clearly laid out within the document itself:

    3.2. Transport-level e-mail forwarding must be more explicit under
         this specification. For example if VIXIE@NETBSD.ORG's
         account has a ".forward" file pointing at VIXIE@ISC.ORG, then
         e-mail sent to the former will be received by the latter, but
         with no change in the payload of SMTP MAIL FROM. Thus, ISC's
         inbound relays would have to be configured to implicitly add
         NETBSD's outbound mail relays as "multistage inbound relays."
         This could scale poorly and may add pressure toward transport
         remailing (with a new envelope) rather than transport
         forwarding (reusing the old envelope.)

No real solution is proposed for the above; if you remail with a new
envelope, how does the original sender get the bounce? And if you
don't, the proposal isn't workable without refusing to support
forwarding at all, which would just encourage mail service providers
to enforce an annoying restriction.

   3.3. Roaming hosts such as laptop computers will probably not be
        able to be listed in the MAIL-FROM MX RR for their return
        address domain name, and may be forced to use an intermediary
        for outbound e-mail. STARTTLS or an SSL/SSH tunnel back
        "home" may become a necessary first hop for mobile e-mail.

The problem that this deals with is the user who needs to dial in to
AOL and send mail from their corporate account. The proposed solution
is to tunnel mail through the corporate server, by proving your right
to relay via SMTP AUTH or else via a VPN.

To make this work well requires support for SMTP AUTH and probably
STARTTLS (unless the company implementing this proposal wants
cleartext passwords flying over AOL's network) for all domains which
want to support Paul's proposal. This isn't necessarily all that
unreasonable, but should be spelled out more clearly, and makes
implementation much more involved.

----ScottG.

11

Point of Information:

  Every single purely technical approach to stopping spam has been a
  complete loser.

I understand the old adage that when all you have is a hammer the
whole world looks like a nail.

And that all many people on this list have is a technical hammer, some
ability to hack around with cisco access lists or similar, so they
tend to hold out hope that some new access list formula might be the
one that saves the day (or similar, don't quibble the example!)

But spam is as much a socio-legal problem as a technical one which is
why, I'd claim, it's been so completely resistant to all purely
technical approaches thus far.

What we need are technical solutions which help with concomitant
socio-legal solutions.

If you haven't noticed, the spammers are winning completely, the
waters are rising rapidly.

More and more legitimate-sounding companies and products are spamming,
and by and large the public perception in the non-anointed* business
community are coming to the conclusion that they receive all this spam
so it must be a legitimate form of advertising.

Let me throw out the following to show how blind the technical
community has been:

  There is no RFC or other public standards document which even attempts
  to define spam or explain, in a careful and professional manner,
  why it is a bad thing.

(before you say the obvious, that's not what RFCs are for, read, e.g.,
RFC 2964)

However, we expect lawmakers to recognize and define the problem and
get it right when the engineers who understand the technology and
problem, in nearly a decade of whining, can't even be bothered to
provide them with robust definitions of what it is the whining is
about.

Food for thought, that's all.

But, personally, I'm hesitant to spend my time trying to study the
merits of yet another anti-spam miracle cure, even if it seems at
first glance (like so many before) that it might foil some particular
flavor of spam which has been prevalent in the past.

Now, after sitting through this extended, multi-day discussion of spam
someone can send me the standard "discussion of spam is not a subject
for nanog!" because I'm not a member of the amen crowd.

* "non-anointed": not a member of the technical community hence
indoctrinated into a particular ethical view of what's right and wrong
on the net.

12

Precisely. It's only an issue for those who implement the feature.
Another thought that came to mind was a sort of hybrid between this and
the central registry of trusted servers.

Rather than maintain a central registry, the mail-from server could
provide its own registry of trusted keys for its own domain. Granted,
this is probably just as complicated as widely implementing SMTP AUTH,
but it does give a little more flexibility for those complaining that
this would break "home-grown" mail servers.

What I am mostly curious about is if there are any potential problems
with those who choose to ignore the feature entirely.

-dvd

13

David Van Duzer <dvanduzer@infidels.org> writes:

>
> The problem that this deals with is the user who needs to dial in to
> AOL and send mail from their corporate account. The proposed solution
> is to tunnel mail through the corporate server, by proving your right
> to relay via SMTP AUTH or else via a VPN.
>
> To make this work well requires support for SMTP AUTH and probably
> STARTTLS (unless the company implementing this proposal wants
> cleartext passwords flying over AOL's network) for all domains which
> want to support Paul's proposal. This isn't necessarily all that
> unreasonable, but should be spelled out more clearly, and makes
> implementation much more involved.

Precisely. It's only an issue for those who implement the feature.
Another thought that came to mind was a sort of hybrid between this and
the central registry of trusted servers.

If a large ISP, say AOL, implements this, and I operate the mailserver
with users who send (relay through me) mail with a from address of
their (legitimate) AOL account, I'm choosing to ignore the feature
entirely, but it's still affecting me and my users.

If a large ISP, say AOL, implements this, and I'm an end-user trying
to send mail with a from address at my (legitimate) AOL account, I'm
choosing to ignore the feature entirely, but it's still affecting me.

I know this isn't what you're looking for, but individual domains
aren't so isolated that you can implement this sort of thing without
zero effect on other mailservers.

You really have to solve the whole problem before it becomes usable at
all. I'm not saying it's an unsolvable problem, just that these two
issues need to be better addressed before it's a usable suggestion.

----ScottG.

14

ISP's should actually block port 25 outgoing, or even better,
reroute/forward it to their own mail relay.

Agreed.

why not do it to port 80 as well? what the hell, why not do it to all
ports? who the hell needs an internet anyway, let's all have a telco
walled garden.

<string of expletives>

can we get back to operating the internet, not killing it?

<another, even longer, string of expletives>

randy

15

Randy Bush wrote:

>> ISP's should actually block port 25 outgoing, or even better,
>> reroute/forward it to their own mail relay.
> Agreed.

why not do it to port 80 as well? what the hell, why not do it to all
ports? who the hell needs an internet anyway, let's all have a telco
walled garden.

<string of expletives>

can we get back to operating the internet, not killing it?

<another, even longer, string of expletives>

Nice rant Randy, but if you even ever wondered why the wording "Mail
Relay" exists you might see that if an
ISP simply forwards all outgoing tcp port 25 traffic to one of their
relays and protects that from weird spam
addresses as a source and only allowing through configured addressess it
would save you, me and the rest
a load of crap which maybe could "kill the internet"...

We didn't invent stuff like SMTP, POP3, IMAP and stuff to be run on
EVERY single node on the internet.

Indeed it limits your clients, just like a NAT does, just like
firewalling does, but it also saves a load of problems.
And maybe your view is "operating the internet" but some people have a
too busy spam/abuse@ mailbox to be
able to do usefull stuff like tracing ddosses, which is yet another
thing people should do but aren't doing: egress filtering.
If (and if) everybody did that, we wouldn't be seeing spoofed addresses,
rfc1918's and other stuff on the internet either
now would we? So pointing these facts out *HAS* something to do with
"operating the internet". <hint> http://as112.net/ </hint>

Greets,
Jeroen

16

Brad Knowles <brad.knowles@skynet.be> writes:

[...]

  Moreover, even if all servers on the Internet were secured in
this manner and there were no open relays, it would also require
perfect reverse DNS because the MXes are listed by name and not IP
address -- that's assuming you do a reverse lookup on the IP address
and require that the returned name is on the list.

The proposal suggests that you get all of the A records for all of the
accepted names, then make sure that one of the A records matches the
address that the connection came from. See sec. 2.3.

Even if it did require good reverse DNS, that would only be needed for
domains that chose to implement this, and only for addresses that
are allowed to send mail from that domain.

----ScottG.

17

The point is that 25 is just a number. You'll eventually be blocking
all numbers sooner or later (and re-inventing dumb terminals).

John

18

John Kristoff wrote:

> Nice rant Randy, but if you even ever wondered why the wording "Mail
> Relay" exists you might see that if an
> ISP simply forwards all outgoing tcp port 25 traffic to one of their
> relays and protects that from weird spam

The point is that 25 is just a number. You'll eventually be blocking
all numbers sooner or later (and re-inventing dumb terminals).

Another person who can't read.

SMTP is a protocol which is based on relaying messages from one
mailserver to another.
An endnode (especially workstations) don't need to run SMTP.
ISP/Company's already have SMTP servers which are setup to relay for
their clients.

So what's so bad about forwarding all tcp/25 traffic over that relay and
letting that relay decide if the MAIL FROM: is allowed to be relayed?
And if a client wants to mail from another domain which isn't relayed by
it's upstream ISP, he/she could ask it's ISP to do so.
Yes this will add an administrative hassle, but doesn't spam imply that
also?

The whole problem is yet again that a small amount of people (this time
spammers) make a whole lot of problems for a lot of people (we).

Also this setup is somewhat the same as checking from an smtp-server
whether the sending server is also actually running an smtp...

Fortunatly we got SpamAssasin/Razor nowadays so the spam that does get
through gets filtered out without bothering me or anybody else using
these tools.

Greets,
Jeroen

19

Actually, I think we did.

Unfortunately it turned out to be a really, really, bad decision.

20

The proposal suggests that you get all of the A records for all of the
accepted names, then make sure that one of the A records matches the
address that the connection came from. See sec. 2.3.

  Right. And when they add a new mail gateway and don't tell you about it? What if they have forty-five of the damn things, each with its own unique name?

Even if it did require good reverse DNS, that would only be needed for
domains that chose to implement this, and only for addresses that
are allowed to send mail from that domain.

  So, if you can't send mail out directly, you pass it on up to your ISP. And if they can't send the stuff directly, they pass it up another level. And so on. And you have to know all the possible IP addresses that could be used as exit points for your mail.

  Yeesh. Ya know, even X.400 wasn't this silly.