Re: [Asrg] Verizon's asymmetrical anti-spam causing problems

Peter Kay wrote:
> Has anyone noticed/experienced Verizon's asymmetrical anti-spam email 
> address verification?  After you connect to their mail servers and send 
> the MAIL-FROM / RCPT-TO commands, before they come back with an OK, they 
> do a reverse check of the MAIL-FROM address to see if it's valid and if 
> not, return a fatal error.
>  
> While Verizon is certainly not the only ISP doing address verification, 
> and I'm personally in favor of the approach, what I object to is that 
> their approach is not symmetrical, meaning that if another server (e.g. 
> Mailsender.com) were to employ the identical method that Verizon does, 
> neither Verizon nor Mailsender.com would be able to send each other email.
>  
> The reason for this asymmetry is that the Verizon probe addresses are in 
> the form of antispamxxxx@west.verizon.net 
> <mailto:antispamxxxx@west.verizon.net> or something to that effect where 
> xxxx is a 4 digit number. So if Mailsender.com used probes like 
> antispamxxxx@east.Mailsender.com 
> <mailto:antispamxxxx@east.Mailsender.com> you can see the problem, that 
> being:
>  
> A. Mailsender sends email to Verizon.
> B. Verizon holds the connection and attempts a probe to Mailsender.
> C. Mailsender holds the connection and attempts a probe to Verizon.
> D. (does this create an infinite loop?)
> E. Verizon's probe fails.
> F. Mailsender's probe fails.
> G. Legitimate email is never sent.
>  
> Has anyone else had problems with this? I did quick check on their site 
> and didn't find anything.
>  
> Have there been any BCP or equivalent on email address verification? I 
> haven't easily found any.

The SAFEST return address for probes of that type would be a null sender 
<>, simply by virtue of it not generating a reply. However, some very 
misguided postmasters block support for null senders, which also 
effectively blocks bounce messages, without having any real impact on 
blocking spam.

Timeouts with fail-open design can help with the above scenario though, 
at the risk of letting some spam through.

I've not seen any BCP on this either, theroretically VRFY is designed 
for the purpose, but nobody in their right mind permits it these days 
because its just as useful for spammers to check their lists.

Maybe an extended VRFY replacement that takes a messageid and an email 
address, and verifies that the server handled a message from that 
sender, with that messageid recently? Of course, this would take years 
to implement, and might not ever get widespread support. (And still has 
its own problems)

_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg