Mailing List Archive

On Feb 18, 13:41, Greg Andrews wrote:
> 3. Receiving mail from the network (tcp-env, qmail-smtpd)
>
> RFC 1123 requires VRFY support, but says that it's okay if an
> implementation can be configured to not allow VRFY. qmail-smtpd doesn't
> allow VRFY. If you desperately want your SMTP server (i.e., inetd) to
> provide useful information for VRFY, just compile and install sendmail.
> Were the RFC 1123 writers aware of the as-if principle of interface
> specification? ... They say that VRFY and EXPN are important for
> tracking down cross-host mailing list loops. Catch up to the 1990s,
> guys: with Delivered-To, mailing list loops do absolutely no damage,
> _and_ one of the list administrators gets a bounce that shows exactly
> how the loop occurred. Solve the problem, not the symptom.

Here is the one thing that bothers me the most about qmail. For all the
good things that qmail does, it also assumes a lot of things whithout
checking for all the answers. There are a lot more uses for VRFY and
EXPN then checking mail loops. For example EXPN can be used to see what
a mailing list expands to, intrestingly enough the name pretty much says
that. I hate to say this, but standards are standards for good reason.
If anyone intends to have qmail as a real contender to sendmail, then
more thought should be given to supporting standard features.

Vlad



--
Vladimir Gabrielescu NBCS System Programmer 1-908-445-4785
vgabriel@toolbox.rutgers.edu http://nbcs.rutgers.edu/~vgabriel/
Someone should have labeled the future 'some assembly required'

Vladimir Gabrielescu <vgabriel@lochaber.rutgers.edu> writes:
>On Feb 18, 13:41, Greg Andrews wrote:
>>>From the THOUGHTS file:
>> RFC 1123 requires VRFY support, but says that it's okay if an
>> implementation can be configured to not allow VRFY. qmail-smtpd doesn't
>> allow VRFY. If you desperately want your SMTP server (i.e., inetd) to
>> provide useful information for VRFY, just compile and install sendmail.
>> Were the RFC 1123 writers aware of the as-if principle of interface
>> specification? ... They say that VRFY and EXPN are important for
>> tracking down cross-host mailing list loops. Catch up to the 1990s,
>> guys: with Delivered-To, mailing list loops do absolutely no damage,
>> _and_ one of the list administrators gets a bounce that shows exactly
>> how the loop occurred. Solve the problem, not the symptom.
>
>Here is the one thing that bothers me the most about qmail. For all the
>good things that qmail does, it also assumes a lot of things whithout
>checking for all the answers. There are a lot more uses for VRFY and
>EXPN then checking mail loops. For example EXPN can be used to see what
>a mailing list expands to, intrestingly enough the name pretty much says
>that. I hate to say this, but standards are standards for good reason.
>If anyone intends to have qmail as a real contender to sendmail, then
>more thought should be given to supporting standard features.
>

First of all, I don't think RFC 821 requires EXPN and VRFY the way
you say it does:

From RFC 821 (retrieved from ftp.uu.net:/inet/rfc/rfc821.Z:

3.3. VERIFYING AND EXPANDING

SMTP provides as additional features, commands to verify a user
name or expand a mailing list. This is done with the VRFY and
EXPN commands, which have character string arguments. For the

[four and a half paragraphs and two examples deleted]

The VRFY and EXPN commands are not included in the minimum
implementation (Section 4.5.1), and are not required to work
across relays when they are implemented.


[skip to section 4.5.1]


4.5.1. MINIMUM IMPLEMENTATION

In order to make SMTP workable, the following minimum
implementation is required for all receivers:

COMMANDS -- HELO
MAIL
RCPT
DATA
RSET
NOOP
QUIT



Second, the usage of EXPN you mentioned has been used many times to
bypass the moderation on mailing lists by discovering the address of
the post-listserver exploder. Then the list is disrupted with ads,
threats, or other off-topic messages. In some cases, the malicious
ones have succeeded in subscribing the exploder address of one list
to a second list, and vice versa. Both lists then erupted in flame
wars over the off-topic messages, and the cross-subscriptions caused
the message volume to quickly spiral out of control.

EXPN has also been used in the past to select accounts at the site
that are vulnerable to attack, by discovering which ones invoke poorly
written shell scripts or filter programs.

VRFY has been used to similar ends, to discover valid login names
on a particular host, despite the efforts of admins trying to keep
them secret. (I'm talking about hosts that do not send out Usenet
postings or outbound e-mail, and don't answer finger requests)


You're right when you say that standards were written the way they
were for good reason. However, the assumption you make afterward,
that qmail ignores parts of some standards without good reason, is
not correct. Whenever I've dug beneath the surface of qmail, trying
to understand Dan's design decisions, I've found good reasons for
them.

Also note that RFC 821 was written in 1982, and RFC 1123 in 1989.
The Internet has changed in many ways in the past 14 and 7 years,
respectively. Parts of those RFCs have been abandoned by the net
(how many MTAs implement SEND and SOML? Or TURN?). I feel that
the net is abandoning EXPN and VRFY also. Their usefulness has
faded. You mentioned Sendmail - were you aware that Sendmail lets
admins disable VRFY and EXPN? Sounds to me as if Eric thinks there
are good reasons to not require an MTA to support them.


In my opinion, EXPN and VRFY are excess interactions that don't
contribute to the overriding goal of an MTA: Transporting E-mail.
Any information about whether a host can deliver to an address can
be found in the response to the smtp "RCPT TO:" command. EXPN and
VRFY are unnecessary to the actual transport of mail, so a mail
transport agent shouldn't be required to support them.


-Greg
--
Greg Andrews West Coast Online
Unix System Administrator 5800 Redwood Drive
gerg@wco.com Rohnert Park CA 94928
(yes, 'greg' backwards) 1-800-WCO-INTERNET

> it also assumes a lot of things whithout checking for all the answers.
> There are a lot more uses for VRFY and EXPN then checking mail loops.

Certainly. The two most common applications are (1) collecting addresses
to spam and (2) poking around for insecure shell commands.

For some reason, RFC 1123 doesn't mention either of these applications.

> For example EXPN can be used to see what a mailing list expands to,

So can finger. finger web@ai.mit.edu, for example.

If you're trying to make information available, you'll do a much more
effective job with finger than with EXPN.

Of course, if you're trying to exploit someone else's misconfiguration,
you'll have much better luck with EXPN.

> I hate to say this, but standards are standards for good reason.

Rarely. Anyway, there's no issue here. RFC 821 doesn't require VRFY.
RFC 1123 requires VRFY (to deal with mailers that can't send mail if
VRFY fails, presumably) but allows it to be completely uninformative.
Neither document requires EXPN.

---Dan
Put an end to unauthorized mail relaying. http://pobox.com/~djb/qmail.html

On 19 Feb 1997, D. J. Bernstein wrote:

>
> > I hate to say this, but standards are standards for good reason.
>
> Rarely. Anyway, there's no issue here. RFC 821 doesn't require VRFY.
> RFC 1123 requires VRFY (to deal with mailers that can't send mail if
> VRFY fails, presumably) but allows it to be completely uninformative.
> Neither document requires EXPN.

ok, not as a standard, as a debugging tool for the local machine... anyone
with a smart script that will let the admin to EXPN on his own system, or
is the only way is piping a test message and switching on some debug mode?

On Wed, 19 Feb 1997, Mark Delany wrote:

> >> VRFY fails, presumably) but allows it to be completely uninformative.
> >> Neither document requires EXPN.
> >
> >ok, not as a standard, as a debugging tool forthe local machine... anyone
> >with a smart script that will let the admin to EXPN on his own system, or
> >is the only way is piping a test message and switching on some debug mode?
> >

> In short, I empathize with your view on VRFY/RCPT, but I think those days
> are numbered and we need to look at other methods for doing what those
> commands did for us. Not especially unique to qmail as a number of other
> MTAs have also gone down the path of incapacitating these commands too.

that's what I was talking about... a commandline thing that will emulate
EXPN...

> ok, not as a standard, as a debugging tool for the local machine... anyone
> with a smart script that will let the admin to EXPN on his own system, or
> is the only way is piping a test message and switching on some debug mode?

In the past 45 mins I whipped up this perl5 script. It's kinda funny, I don't
think of myself as a programmer anymore, but I'm clearly more of a programmer
than a lot of people on this list.

I can't promise that there aren't bugs or improvements to be made to this
script since I hacked it up quickly. (It doesn't handle -default qmail files,
for instance.)

On Tue, 18 Feb 1997, Vladimir Gabrielescu wrote:

> Here is the one thing that bothers me the most about qmail. For all the
> good things that qmail does, it also assumes a lot of things whithout
> checking for all the answers. There are a lot more uses for VRFY and
> EXPN then checking mail loops. For example EXPN can be used to see what
> a mailing list expands to, intrestingly enough the name pretty much says
> that. I hate to say this, but standards are standards for good reason.
> If anyone intends to have qmail as a real contender to sendmail, then
> more thought should be given to supporting standard features.

you have the source, add the necessary code.

RjL

I agree with another poster on this matter. As a heavy-duty ISP, we find
that EXPN/VRFY are unfortunately abused too much. When we ran sendmail we
turned all that stuff off (1 in 100 VRFY commands were a postmaster
diagnosing a problem, 99 in 100 were a spam mailer checking email addresses
- sigh).

It's a pity as I used to use such commands to help diagnose problems in a
bygone era, but those days are pretty much gone I think.

The question you have to ask is: "what exactly are you diagnosing that a
real mail to the recipient wont test?". If I'm checking an email address and
everything looks good (eg, MX records valid, MX host runs a real MTA)
then I simple send a mail to the recipient (whether by a UA or SMTP direct)
with a polite note saying "this is a test mail from XX just to ensure YY,
please ingore blah blah".

If the mail delivers most everyone on the receiving end I've dealt with has
been more than helpful. If it bounces, the bounce tells you as much as (or
more than) a VRFY/EXPN does.

If it's a list that's a slight complication, but I think even the most
pernicky list recipient doesn't mind an occassional irrevelant mail if it's
initiated for the right sort of reasons.

In short, I empathize with your view on VRFY/RCPT, but I think those days
are numbered and we need to look at other methods for doing what those
commands did for us. Not especially unique to qmail as a number of other
MTAs have also gone down the path of incapacitating these commands too.


Regards.


At 11:17 AM 2/19/97 +0200, Ira Abramov (at work) wrote:
>On 19 Feb 1997, D. J. Bernstein wrote:
>
>>
>> > I hate to say this, but standards are standards for good reason.
>>
>> Rarely. Anyway, there's no issue here. RFC 821 doesn't require VRFY.
>> RFC 1123 requires VRFY (to deal with mailers that can't send mail if
>> VRFY fails, presumably) but allows it to be completely uninformative.
>> Neither document requires EXPN.
>
>ok, not as a standard, as a debugging tool for the local machine... anyone
>with a smart script that will let the admin to EXPN on his own system, or
>is the only way is piping a test message and switching on some debug mode?
>
>
>