ietf-smtp
[Top] [All Lists]

Re: not delivering, and History of fallback to A

2008-03-31 18:40:43

I've been reading this exchange with an emotion that varies between
amusement and bemusement, and I've come to the conclusion that Ned
and John must be talking about different things.

There are two ways of looking at this problem.  I'm pretty sure that
both are saying that this only applies to AAAA records, since
regardless of the merits it's just too hard to require MX for IPv4
hosts given where we are today.

Not exactly. The issue isn't what to do in general, it's what to do in this
document. I have no problem with someone starting an MX . effort or a require
MX effort and seeing if they can get consensus on it. (If the former gets
started I plan to support it, the latter I'll oppose.) It just doesn't belong
in 2821bis.

Some feel that the transition to
IPv6 is a once-in-a-lifetime opportunity to make some of these
fundamental changes.

And some of us feel that coupling such changes is ill advised.

So let me postulate a world in which IPv4 is
gone, A records are gone, and IPv6 reins over the planet, and we have
switched to requiring MX for any inbound mail hosts.

That's somewhat uninteresting to me because I don't think it will happen in any
sort of time frame frame we're concerned with. What we might get to is a
situation where it is feasible to run a server with only IPv6 and not IPv4. But
even that isn't going to happen any time soon.

Ned seems to be thinking about the bad guys, saying "So what?
Spammers are going to try to send to hosts whether or not they have
MX records, so what's the point?"

Well, I'm thinking about the bad guys only to the extent that I don't want to
give them any more opportunities to cause harm than they already have. Again,
this is about 2821bis, not about getting anyone's, let alone everyone's,
favorite spam fighting mechanism onto the standards track. And I have yet to
hear a convincing explanation for how AAAA fallback changes the situation for
bad guys in any appreciable way.

Of course spammers are highly unpredictable, often to the point of acting
against their own best interests, so it is impossible to say with assurance
that given we do this it cannot possibly lead to that. The best we can do is
guess, and my assessment is that it is best not to make an architectural shift
as part of adding IPv6 support.

Clearly hosts that are not pointed
to by any MX record will either have a rogue SMTP server (which more
or less by definition will only receive spam) or it won't respond on
port 25 (and so the client side will time out), but in either case it
makes no difference to the legitimate mail flow which will never even
try to connect to such hosts (remember, we're in a world that doesn't
fall back to AAAA). I don't think John is in any sense saying that
spammers will suddenly go to finishing school and stop their boorish
behavior, and hence only disagrees with the "what's the point?" part.

Yes, I think so.

John seems to be thinking about the good guys, saying "But consider
the good guys who are being unwillingly drawn into this battle."  In
particular, blowback is a horrid problem, which, if the purported
sending return-path address actually gets to a live SMTP server, is a
scourge upon the people, whether or not the local-part is legitimate.
In this world, legitimate SMTP clients will note that they are trying
to send a message to a mailer that does not accept mail and
presumably drop that message on the floor rather than contribute to
the problem.

I confess that I agree with both of them on some level.  Such a move
will decrease blowback from legitimate mailers.  But it isn't at all
clear to me that such a move will be a significant improvement since
the spammers can just choose return-paths with domains that accept
mail.

It's interesting that you characterize this as being a possible future action.
From where I sit it is already reality: Spammers are overwhelming already using
legitimate MAIL FROM addresses. (I suspect this is due to some very large ISPs
performing reverse address validity checks. And please, let's not get
sidetracked onto how such checks are a bad idea. I'm condoning nothing, merely
staring what I know for a fact has been done on a large scale.) Even worse,
I've seen some rather chilling indications that they are now attempting to pair
up the "right" MAIL FROM with each RCPT TO.

It is clear to me that if identifying hosts that are
legitimate mail receivers is a good thing, then the right thing to do
is label the legitimate receivers rather than the non-receivers, as
the latter outnumber the former by a huge (and growing) ratio.

Well, as it happens I have a printer that accepts jobs via SMTP... (It's
actually pretty funny - many of the responses are misspelled, it always
identifies itself as example.com, and so on.) Actually something of a pain
since I have to make sure to block traffic to it lest it start spewing
printouts of spam.

Aesthetically I like the idea of such labeling, but I'm having
trouble coming up with a good technical argument for it, based in
part on Ned's discussion.  I just can't find justification for John's
claim that "[i]t's going to change the way that MTAs are set up which
will make it harder for spammers to abuse."

I like the idea of labelling services too - in theory. In practice we have a
huge installed base that's under continuous attack and a network that needs to
transition to a new infrastructure and which, as far as I can tell, is moving
very slowly if at all.

Just for the record, sendmail has /never/ "report[ed] back every two
hours to say that your message hasn't bounced yet".  It will report
back exactly once per message saying that your message has been
delayed (but indeed hasn't bounced), but will never do that more than
once per message.  And sendmail respects DSN NOTIFY requests, so it's
trivial for the message sender to turn it off entirely.

Our MTA is configurable in this regard and while the defaults are sensible a
surprising number of sites insist on getting multiple notices on a fairly short
time scale. And we also support DSN, but sadly not that many messages use it to
suppress unnecessary notifications.

                                Ned