Prev: address rewriting for remote clients
Next: Rejecting invalid email addresses with SMTP relay/forward
From: mouss on 27 Dec 2009 15:45
Stan Hoeppner a �crit :
> Len Conrad put forth on 12/26/2009 3:49 PM:
>
>> Requiring HELO is hardly an RFC-abusive setting. I expect almost no legit, nor illegit, SMTP servers send EXPN or VRFY before helo,
>
> I'll add that just about everyone disables VRFY these days to prevent valid
> address harvesting, so if 5321 or any other RFC requires accepting VRFY then we
> are all out of RFC compliance.
>
> Concentrate on the aspects of RFCs that allow you to send/receive email to/from
> legitimate sites. Be loose with those that impede your ability to stop spam.
> We've all read various places that over 90% of all email attempts/transactions
> are spam. The authors or the relevant SMTP RFCs did not take this fact into
> account last they wrote these documents. Look at the creation and last modified
> dates on these RFCs and you'll fully understand that they are behind the times
> WRT dealing with spam.
>

5321 dates back to last year (October 2008). The
authors/contributors/... were fully aware of the spam problem.

Keep in mind that:
- (good & working) design is difficult
- consensus is not easy
- a design that changes every time there is a new "thing" (spam or
whatever) is useless.

Long before spam was what it is today, the old smap (from the FWTK) used
to cheat with VRFY and EXPN (it echoed the address and claimed it had
verified it and for EXPN, any address expands to $self). In fact, smap
didn't validate addresses, so it couldn't do much for VRFY and EXPN
(backscatter wasn't a problem at the time). The point is: the problems
surrounding VRFY and EXPN were known since very long. Even before 2821
(April 2001).

From: Ansgar Wiechers on 27 Dec 2009 17:34
On 2009-12-27 John Peach wrote:
> On Sun, 27 Dec 2009 20:22:33 +0100 Ansgar Wiechers wrote:
>> On 2009-12-26 Stan Hoeppner wrote:
>>> I'll add that just about everyone disables VRFY these days to
>>> prevent valid address harvesting,
>>
>> Which, of course, is utterly pointless.
>>
>> HELO example.org
>> MAIL FROM:<probe(a)example.org>
>> RCPT TO:<address_to_be_verified(a)example.net>
>> QUIT
>
> wrong.
>
> there is a world of difference between;
>
> 502 5.5.1 VRFY command is disabled
>
> and
>
> 250 2.1.5 Ok
>
> or
>
> 550 5.1.1 <redacted> Recipient address rejected

Perhaps I'm missing something, but I fail to see the big difference when
it comes to address verification. Regardless of whether you use VRFY or
MAIL FROM/RCPT TO/QUIT, if the address is invalid the response will be

550 5.1.1 <address_to_be_verified(a)example.net>: Recipient address rejected

If it isn't, the address can be considered verified. Unless, of course,
the server produces backscatter. Which it shouldn't.

Regards
Ansgar Wiechers
--
"Abstractions save us time working, but they don't save us time learning."
--Joel Spolsky

From: John Peach on 27 Dec 2009 18:14
On Sun, 27 Dec 2009 23:34:47 +0100
Ansgar Wiechers <lists(a)planetcobalt.net> wrote:

> On 2009-12-27 John Peach wrote:
> > On Sun, 27 Dec 2009 20:22:33 +0100 Ansgar Wiechers wrote:
> >> On 2009-12-26 Stan Hoeppner wrote:
> >>> I'll add that just about everyone disables VRFY these days to
> >>> prevent valid address harvesting,
> >>
> >> Which, of course, is utterly pointless.
> >>
> >> HELO example.org
> >> MAIL FROM:<probe(a)example.org>
> >> RCPT TO:<address_to_be_verified(a)example.net>
> >> QUIT
> >
> > wrong.
> >
> > there is a world of difference between;
> >
> > 502 5.5.1 VRFY command is disabled
> >
> > and
> >
> > 250 2.1.5 Ok
> >
> > or
> >
> > 550 5.1.1 <redacted> Recipient address rejected
>
> Perhaps I'm missing something, but I fail to see the big difference when
> it comes to address verification. Regardless of whether you use VRFY or
> MAIL FROM/RCPT TO/QUIT, if the address is invalid the response will be
>
> 550 5.1.1 <address_to_be_verified(a)example.net>: Recipient address rejected
>
> If it isn't, the address can be considered verified. Unless, of course,
> the server produces backscatter. Which it shouldn't.
No it is not.

502 5.5.1 VRFY command is disabled

just tells you that VRFY has been disabled; not the validity of the
address.

--
John

From: Glenn English on 27 Dec 2009 18:37

On Dec 27, 2009, at 4:14 PM, John Peach wrote:

> 502 5.5.1 VRFY command is disabled
>
> just tells you that VRFY has been disabled; not the validity of the
> address.

Far be it from me to speak for Ansgar, but on my postfix server, if VRFY doesn't work, it's trivial to just say HELO/MAIL FROM/RCPT TO to get an address verification. I only have to H/MF once -- it will respond to RFs for longer than I have patience to test it.

The big difference is that it logs failed RFs, but doesn't seem to log anything about VRFY tries (VRFY is disabled).

--
Glenn English
ghe(a)slsware.com

From: Ansgar Wiechers on 27 Dec 2009 18:39
On 2009-12-27 John Peach wrote:
> On Sun, 27 Dec 2009 23:34:47 +0100 Ansgar Wiechers wrote:
>> Perhaps I'm missing something, but I fail to see the big difference
>> when it comes to address verification. Regardless of whether you use
>> VRFY or MAIL FROM/RCPT TO/QUIT, if the address is invalid the
>> response will be
>>
>> 550 5.1.1 <address_to_be_verified(a)example.net>: Recipient address rejected
>>
>> If it isn't, the address can be considered verified. Unless, of
>> course, the server produces backscatter. Which it shouldn't.
>
> No it is not.
>
> 502 5.5.1 VRFY command is disabled
>
> just tells you that VRFY has been disabled; not the validity of the
> address.

You're missing the point. When you find that VRFY is disabled, you'd
simply use

MAIL FROM:<a(a)example.com>
RCPT TO:<address_to_be_verified(a)example.net>
QUIT

instead of VRFY.

If the server doesn't produce backscatter (i.e. accepts first, bounces
later), the result of the above sequence will tell you whether or not
<address_to_be_verified(a)example.net> is valid.

Regards
Ansgar Wiechers
--
"Abstractions save us time working, but they don't save us time learning."
--Joel Spolsky

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: address rewriting for remote clients
Next: Rejecting invalid email addresses with SMTP relay/forward