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(_at_)west(_dot_)verizon(_dot_)net
<mailto:antispamxxxx(_at_)west(_dot_)verizon(_dot_)net> or something to that effect where
xxxx is a 4 digit number. So if Mailsender.com used probes like
antispamxxxx(_at_)east(_dot_)Mailsender(_dot_)com
<mailto:antispamxxxx(_at_)east(_dot_)Mailsender(_dot_)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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg