Keld Jørn Simonsen wrote:
On Wed, Feb 11, 2004 at 09:18:42AM -0500, Bruce Lilly wrote:
For what I describe, it is only necessary to do it at final delivery,
when this is permissable anyway. My idea is to swop the check for bad
data with the checks for valid user and mailbox overflow and such.
This would then reduce the amount of error messages for 'no such user'
or 'mailbox full' - as these errors for the bogus mail will be
eliminated.
Here's the problem: your SMTP receiver gets a connection from a client.
The session is started, MAIL FROM, RCPT TO (which you don't check), and
DATA. At the end of the message, you check for virus/spam/whatever and
find none, Then you get around to checking the recipients and find that
(e.g.) 3 out of 12 are invalid. You can't send a 2yz return code for
DATA, because you can't deliver to invalid addresses. You have to send
a [45]yz response. And as pointed out in the 2821 section that I referred
you to, that presents a problem for the sender (*which* address(es) were
responsible for the failure?). If you deliver to the valid recipients
and the sender resends (perhaps guessing which recipients were invalid,
or sending multiple individual copies), those recipients will receive
duplicates.
Specifically in the case of the recent "MyDoom" variants, the worm uses
an internal SMTP client engine, so on detecting an invalid recipient at
the RCPT TO stage and returning a 5yz code immediately, there is no
delivery and no bounce, as there is no intermediate SMTP relay. The
bounces in those recent cases are caused precisely by systems that
operate as you suggest; i.e. they do not check for invalid recipients
at RCPT TO.
The text following a 554 response can be embellished. Ideally any 5yz
response other than the ones specifically mentioned in 2821 should only
be used if some suitable ESMTP extension is negotiated. There may be
some old SMTP clients that do not handle any codes other than the
specified legal ones correctly.
Well, it could be handled in another way, as also described in response
to Hector.
If the sender uses EHLO and agrees to whatever extension corresponds to
additional error codes. Otherwise you should fall back to the standard
code, viz. 554.
Well, I wanted as final receiving MTA to discard the message, the sender
address is bogus anyway.
Not necessarily -- your virus/spam detector might have provided a false
positive to legitimate mail with a valid sender envelope address. Once
an intermediate MTA has issued a 2yz response to DATA and subsequently
encounters an error on transfer to a downstream SMTP server, it is
obligated to send a non-delivery message to the specified sender envelope
address (if not null).
Yes, false negatives are always something to consider. But they will
happen anyway (with current spam technology such as spamassassin).
A very small error rate is tolerable, at least to me.
I am not talking about intermediate MTAs, only final delivery.
If there's an intermediate MTA, there will be a bounce (that is a good
thing in the case of legitimate mail!). It also applies to spam, etc.,
so the joe-job victim will still get the bounce. Note that below you
advocate use of intermediate relays, which essentially guarantees a
bounce message.
That might be true for legitimate mail, but you can't prevent a
spammer or virus author from using HELO rather than EHLO. Servers
MUST support HELO (2821 sect. 4.1.1.1). Not all clients or servers
that support some ESMTP extensions support all extensions.
Yes, spammers may use HELO. But do we care for spammers?
I don't:-) So we need not treat them well...
You may have missed the point. You are obliged to support HELO, and
if a spammer or virus author chooses to use plain SMTP, no mechanism
that depends on an extension will be effective. And as email is a
critical application and there are many SMTP servers in use, not
all of which support ESMTP, you cannot (if you wish to be compliant
with RFCs 821 and 2821) simply refuse to accept HELO. You could
of course run a non-compliant server at the risk of being isolated
from those sending with plain SMTP. You could also become a hermit
and take up residence in an isolated cave.
That should be clear if a delivery status notification (DSN) is used.
If a DSN is not being used, either plain SMTP is being used or the
DSN extension is not supported.
Hmm, I don't think we have seen spammers use DSN yet, but they may do,
just to increase the chaos they generate.
The spammers don't, but if a bounce is generated, DSN is the preferred
format if the necessary ESMTP extensions are available. I've seen
both DSN bounces and non-DSN bounces.
IP-addresses would be my choice of identification.
I would not guarantee dynamic addresses to be able to run an MTA.
Removal of the blocking could be done just by some web interface,
However, it should not be doable by software, only by manual
intervention.
Some thoughts should be done to caveats, I am not fully sure if it would
work, but would like to see it in action. How do those professional
firms do it, that sell such blacklists? And there are projects that
already does this RBL service, although not well maintained.
There have been horror stories of people who have been inappropriately
blacklisted and who have been unable to be removed from the respective
blacklist. And there are blacklist operators who have no compunction
about blacklisting an entire ISPs address range because one user had a
worm. This is a very real problem with blacklists.
True, they are names. But then people should avoid names like ".com".
Why? Because Microsoft's programmers are too lazy or too incompetent
to check file content to determine type? That's not a very compelling
reason to avoid a name. It may be a compelling reason to avoid
Microsoft's products, but that's another matter.
And yes, they use .zip - to me that means that .zip files are not
useable anymore on the net. We have to adapt to this hostile world,
and not sending .com or .zip files is one of the small offers
we may need to do.
Nonsense. It means that software suppliers need to pay attention to
the rules, which have been clearly stated, with background information,
for well over a decade. It also means that users need to take
responsibility for their actions. If you aren't sure who sent a
file, don't try to run it as an executable! People should learn that
as small children; "don't accept candy from a stranger". Certainly
I was taught that many decades ago -- one wonders how so many people
managed to have irresponsible parents; but that's also another matter.
You are right, but we could stop them from arriving in our mailboxes,
at least in the more knowledgeable users mailboxes (including the users
that are wise enough to choose the right ISPs). What I describe does
avoid code red and MyDoom to arrive in *my mailbox* and even others
bogus error mail that *I* sent them virus could be avoided in my own
mailbox. That is, I think this could be the result, but I invite others
to analyse whether that is true.
It does not. If you run no Microsoft products, have never sent spam,
and run your own MTA as you suggest, you may still receive bounces
from somebody else's MTA because some clueless user looked at a
virus-infected message in the preview pane of an unpatched version of
Microsoft Outlook. You have no control over the configuration of
somebody else's SMTP server, and you can't force some clueless user
to keep up with a constant stream of band-aid patches from Microsoft
(which in any event provide no protection against the next day's
exploits (http://www.eeye.com/html/Research/Upcoming/index.html)).
True. But there are also other users that do update their AVS on a daily
basis.
And you get what you deserve if you dont protect yourself against virus.
The problem is that users with no susceptibility experience the collateral
damage from Microsoft's weapons of mass email destruction, such as via
the bounces that you're complaining about. You can't force any of
your suggestions on others; of what you've suggested, about the best
you can do is to try to convince SMTP receiver operators to return 554
at the end of DATA if a virus is detected. And there are dangers with
false positives.
One idea is that the customer on a dynamic IP always should use the MTA
of the ISP - who then does proper scanning of incoming mail for virus
and spam. If the dynamic IP customers don't, then good luck!
Some ISPs require that, and enforce it by blocking traffic to port 25
except from their internal servers. I'm not aware of any that do that
who also scan for virus/spam. That can be annoying to legitimate users
who occasionally need to work around problems with the ISPs servers or
DNS cache. It doesn't slow down miscreants, who can easily find an open
relay or web proxy on a different port.
That also enforces a different model for SMTP transfer from the original;
effectively the ISP is an SMTP relay (hopefully not an open one).
Not all SMTP clients are MTAs (RFC 2821 section 2.3.8). MUAs can be SMTP
clients, and an MUA on a machine with a dynamic address (like this one)
is not at all unusual.
Yes, dynamic IP SMTP agents are not unusual. I once did that too, but
now I got a fixed address ADSL for my home machine.
Anyway what do you propose for such animals?
SMTP AUTH seems to work, using the ISP's ESMTP relay (which supports AUTH)
with a MUA client that also supports SMTP AUTH. However, it is not practical
for MTA-MTA transfers, and an SMTP receiver can't readily tell if a client
is an MUA or an MTA.
What about your ISP, do they not provide you with a mail relay service?
Most ISPs do.
My ISPs do. Neither blocks outbound port 25 (which I occasionally have to
use to work around problems). One requires SMTP AUTH, another appears to
use a different authentication mechanism. As noted above, use of such an
intermediate relay can be a contributing factor to the bounce problem.
I occasionally have to connect to the Internet via a network that does
block outbound port 25 traffic, and that is a nuisance.