jaugustine@verizon.net wrote:
I have received many emails from my son (*****@att.net) over the years into my gmail inbox.
I don't think it's what you think it is.
This started about a month ago and concerns email coming from att.net, sbcglobal.net, ameritech.net and maybe others that used to be in the baby
bell systems.
For whatever reason they are sending mail out via servers that claim to be yahoo.com...
Nov 1 18:24:12 s_local@zone3 sendmail[25848]: [ID 801593 mail.info] 2A1NO6Lp025848: from=<
xxx@sbcglobal.net>, size=17339, class=0,
nrcpts=1, msgid=<
C0AB5FF5-AF92-4767-AB5E-A299AC75D720@sbcglobal.net>, proto=ESMTPS, daemon=MTA, relay=sonic305-25.consmr.mail.ne1.yahoo.com [66.163.185.151]
but mail you are sending to them is going thru prodigy.net (!?!)...
Nov 6 09:55:53 s_local@r1 sendmail[26302]: [ID 801593 mail.info] 2A6FtnGK026300: to=<
xxx@sbcglobal.net>, delay=00:00:04,
xdelay=00:00:02, mailer=esmtp, pri=221383, relay=al-ip4-mx-vip1.prodigy.net. [144.160.235.143], dsn=2.0.0, stat=Sent (2A6FvpPa097264 Message accepted for delivery)
I don't know if the two (yahoo/prodigy) merged or this is just some major fuckup for those ex-baby bell systems.
What this causes is a total failure of "sender policy framework (SPF)" and
the "sender address verification (SAV)". It doesn't seem like the user lists are shared and there is no policy framwork:
Nov 1 18:24:12 s_local@zone3 smf-spf[29786]: [ID 862159 mail.info] SPF
none: 66.163.185.151, sonic305-25.consmr.mail.ne1.yahoo.com, sonic305-25.consmr.mail.ne1.yahoo.com, <
xxx@sbcglobal.net>
Google on the other hand seems to check for SPF and dkim:
Nov 6 08:43:54 s_local@r1 sendmail[24881]: [ID 801593 mail.info] 2A6EhlKc024879: to=<
xxx@gmail.com>, delay=00:00:07, xdelay=00:00:07, mailer=esmtp, pri=203997, relay=alt4.gmail-smtp-in.l.google.com. [209.85.202.26], dsn=4.0.0, reply=421 4.7.0 This message does not pass authentication checks (SPF and DKIM both do, stat=Deferred: 421-4.7.0 This message does not pass authentication checks (SPF and DKIM both
(the error message is truncated)
but since google doesn't throw anything out, it's placed into the spam
folder over there.
Thats my theory.
So that is why you can't find any spam-bypass for his email address, it's on the front end. They aren't rejecting it but giving a temp fail message (reply=421 4.7.0) and taken in on the next queue run.
Pin the blame on att.net (and the others) because up to a month ago, it used
to work fine (yahoo in and out). With mail being split inbound and outbound, lack of SPF, google you can say is doing the right thing.
-bruce
bje@ripco.com
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)