> Regarding the above, I have the following question:
>
> What do you (and maybe other people on the list) think about such email
> verification method ("abusing RCPT TO") used as part of:
>
> a) mail receiving process - I'm thinking here for example about the Postfix
> feature "reject_unverified_recipient" that checks sender's email using this
> method before accepting (or rejecting, if sender's email doesn't verify) the
> message (see http://www.postfix.org/ADDRESS_VERIFICATION_README.html ). Some
> other MTAs have similar features too, there are also milters that do this.
Yes, Sender Address Verification is abusive as well because it causes
the systems doing it to woodpecker on anybody whose addresses are forged
as senders in spam.
And so is Challenge/Response based spam filtering.
> b) website registration process - some time ago I was maintaining some
> website where people often mistyped their email addresses. Due to the
> nature of the website the typical "click on confirmation link that
> arrives via email" approach could not be used
List members will probably argue eloquently for why "could" is the
wrong word to use here. I don't mean there is anything wrong with
your grammar, your language is perfectly fine.
> anything except the registration form). So I included the code that did the
> email verification ("abusing RCPT TO") upon form submission, and in case of
> a verification failure, asked the user to correct the address.
...potentially causing some users not to be able to fill in the form
at all if the receiving email system was aware of such attempts and
refused to serve them. ;)
> Do you think using this method of email verification in such cases
> is OK or not?
If it is, then it must be OK in all cases. This is, after all, the
intended use case for Radek's system as per his previous correspondence.
But I don't think it is.
In my opinion, whether you do it yourself or outsource it to a partner
cannot be a factor in whether it is abusive. Neither is the volume. The
main bit is that the creator of any such system has observed the fact
that EXPN and VRFY are no longer available, so they have decided to
circumvent this fact and impose themselves on the mail server owners
in ways they can't pre-emptively break without breaking all email.
The solution to that, then, is rejecting all connections from such
systems, either within SMTP or on the network level. But doing that
requires observing where it is coming from first.
Those blocks tend to be of a set-and-forget nature.
--
Atro Tossavainen, Founder, Partner
Koli-Lõks OÜ (reg. no. 12815457, VAT ID EE101811635)
Tallinn, Estonia
tel. +372-5883-4269, http://www.koliloks.eu/
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
