Re: [mailop] Delivery issues with libero.it / virgilio.it (IOL)

[Stefano Bagnara via mailop]

Hi Claudio,

About Libero (IOL) try to use a single connection. I got that error by
using 2 concurrent connections from the same IP: you can send very
fast but you can only use a single connection. I've never been able to
get in touch with a Libero postmaster recently.

About Yahoo from what I saw they have an hourly rate limiting that is
being reset at the 30 minute of each hour and a daily limit that
resets at 3 in the night (CET): the 2 limits depend on your IP
reputation, so you can try delaying 1 hour for the first retries and 1
day for the next ones, until yahoo learn your IP reputation. Yahoo
postmaster is here in the list.

Stefano

On Thu, 4 Apr 2024 at 01:07, Claudio Faoro via mailop  wrote:
>
> Hi everyone,
>
> a couple of weeks ago I configured a new Postfix server, it's used 
> exclusively by a newsletter service with 2 subscribers.
> The newsletter service has been active for more than 10 years on a very old 
> server running qmail.
> Unfortunately, I had to decommission the old qmail server in a few days, 
> replacing it with the new one. It was not possible to keep the same IP 
> address.
> I've correctly configured the SPF, DKIM, DMARC and PTR records 
> (mail-tester.com gives me 10/10).
> The first few days, I had problems delivering mail to several providers due 
> to the amount of messages. I guess it's partly due to the new IP.
> For example:
>
> Mar 30 15:37:00 mx1 postfix/smtp[2021]: 6940F7FF09: to=, 
> relay=mx-eu.mail.am0.yahoodns.net[188.125.72.74]:25, delay=3473, 
> delays=0.47/3472/0.71/0.04, dsn=4.7.0, status=deferred (host 
> mx-eu.mail.am0.yahoodns.net[188.125.72.74] said: 421 4.7.0 [TSS04] Messages 
> from REDACTED temporarily deferred due to unexpected volume or user 
> complaints - 4.16.55.1; see https://postmaster.yahooinc.com/error-codes (in 
> reply to MAIL FROM command))
>
> After a few mailings, the situation seems to have stabilized, Yahoo no longer 
> gave me problems.
> Unfortunately, a good percentage of our subscribers use an email address from 
> Italiaonline/IOL (libero.it, virgilio.it, iol.it, inwind.it, etc...).
> Most of the emails to IOL get bounced:
>
> Mar 30 00:15:40 mx1 postfix/smtp[51700]: 509762617D: to=, 
> relay=smtp-in.libero.it[213.209.1.129]:25, delay=116950, 
> delays=116848/101/0.09/1.1, dsn=4.0.0, status=deferred (host 
> smtp-in.libero.it[213.209.1.129] said: 451 too many messages, slow down. 
> [smtp-22.iol.local; LIB_650] (in reply to end of DATA command))
>
> The limit is triggered very quickly and it's removed after several hours.
> I tried to throttle the sending to IOL addresses on Postfix 
> (destination_concurrency_limit = 2 and destination_rate_delay = 300s), but I 
> keep getting capped after a while.
> I don't have much information regarding the old qmail server, but it seems 
> that there were not all these problems (there wasn't even DKIM and DMARC 
> configured!).
>
> I don't understand how to resolve these problems with the libero.it mailboxes 
> (and more generally, with all Italiaonline mailboxes). Do you have a contact 
> in Italiaonline who can help me?
> Any info would help me, thanks in advance.
>
> Regards,
> Claudio



-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Google unsolicited mail rejected with 421

[Stefano Bagnara via mailop]

On Thu, 14 Mar 2024 at 10:09, Marco Moock via mailop  wrote:
> Mar 14 06:54:17 srv1.xyz sm-mta[498019]: 42DK6aqc496761:
> to=, delay=09:47:40, xdelay=00:00:03, mailer=esmtp,
> pri=5370980, relay=alt4.gmail-smtp-in.l.google.com., dsn=4.7.28,
> reply=421 4.7.28 Gmail has detected an unusual rate of unsolicited mail
> originating, stat=Deferred: 421-4.7.28 Gmail has detected an unusual
> rate of unsolicited mail originating

The full message from Gmail gives you more hints about the problem: it
may be a rate limiting for the DKIM signing domain, for the SPF
domain, for an URL included in the email, for the sender and so on.

E.g. the full message could be like this:
421-4.7.28 Gmail has detected an unusual rate of unsolicited mail originating
421-4.7.28 from your DKIM domain [#redacted#  36]. To protect
421-4.7.28 our users from spam, mail sent from your domain has been temporarily
421-4.7.28 rate limited. For more information, go to
421-4.7.28  https://support.google.com/mail/?p=UnsolicitedRateLimitError to
421 4.7.28 review our Bulk Email Senders Guidelines. #redacted# - gsmtp

The SPF tempfail error starts with the same words, too.
The URL one have a different prehamble.
I don't know how many other errors you can get, but if you want to
investigate you need the full error.

> It was only this message. Why don't they reject them with 5xx when they
> treat the mail as unsolicited?

They give you a tempfail because it is a rate limiting: so if you try
later it usually will work.

> It was only this mail, my server wasn't abused by spammers.
>
> Although, I send only a very small amount of mail to Google. Do they
> use that to calculate the rate?

You need the full message to make a better guess, but, for example, if
Google is receiving a lot of spam with a given URL domain in the body
it may start rate limiting that content from every source, including
you.

Stefano

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Love how people use SPF records.. Just for a chuckle..

[Stefano Bagnara via mailop]

On Tue, 12 Mar 2024 at 00:01, Michael Peddemors via mailop
 wrote:
> save.ca descriptive text "v=spf1 ip4:70.33.236.0/25  mx a
> include:sendgrid.net include:thestar.ca include:thestar.com
> include:spf.google.com include:spf.protection.outlook.com
> include:spf.yahoo.com include:spf.aol.com include:amazonses.com -all"
> [...]
> I assume someone that likes spamming set THAT one up.. there is a good
> reason that SPF have a maximum DNS amount of queries..

Their record requires 35 DNS lookups to be completely evaluated :-)

The "include:thestar.ca" alone uses 15 DNS lookups (I wonder if they
suggest anyone to use this include or if this is a mistake from
save.ca).

Anything after include:thestar.ca (and also part of this included
record) will be ignored and result in permerror, so their record
equals to "v=spf1 ip4:70.33.236.0/25  mx a include:sendgrid.net
include:thestar.ca -all".

Maybe the RFC could have defined to return *fail* instead of permerror
when you can detect the record will need more than 10 DNS lookups just
looking at it (like this one: you don't even need to recurse into the
includes to know this record requires more than 10 lookups).

I don't think this is an indicator of a spammy sender: spammer are
usually good at understanding how to propertly authenticate their
emails. I saw similar SPF records with too many lookup and invalid
hosts in many domains where the sysadmin probably saw a couple of SPF
records and thinks he master SPF and fixes any deliverability issues
by adding new include there, as it worked the first time.

Stefano
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] freenet.de routing issues anyone? (Cloudflare-OVH issue?)

[Stefano Bagnara via mailop]

On Mon, 11 Mar 2024 at 18:10, Alexandre Dangreau via mailop
 wrote:
> I see the issue is solved, but I’m interested of the solution you found.

The solution was writing to peer...@mcbone.net (the address I found in
the RIPE DB for their AS). The email had also n...@ovh.net as a
recipient.

When they replied to me they also replied to n...@ovh.net.

Today I also received a feedback from postmas...@freenet.de (he
probably was not aware about my email to  peer...@mcbone.net and their
reply).

> If an OVHcloud’s customer have any network issue, he can contact the support 
> team.
> They know how to make network test to identify if it’s network issue (e.g. : 
> peering)
> or other issue (e.g. : blacklist) and can escalade to the right team if 
> needed. Did youù
> contact the support team ? If yes, please provide me the ticketID and I’ll 
> check what they did.

Sure, the ticket number is 9397742.

I closed the issue when I got the reply from freenet, including the
reply from freenet.

Stefano

> -- /n
> Alexandre Dangréau
> Head of Trust & Safety
> VU.Ethics & Compliance
> M : +33 (0)669337320
> https://twitter.com/ovhcloud | https://www.linkedin.com/company/ovhgroup/ | 
> https://www.ovhcloud.com/fr/
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] freenet.de routing issues anyone? (Cloudflare-OVH issue?)

[Stefano Bagnara via mailop]

On Fri, 8 Mar 2024 at 17:47, Stefano Bagnara  wrote:
> > Poking a few people, this looks like a return path issue on Freenet's
> > side; So they likely fnorded something on their side.
> > Guess the only way to get this fixed is for them to realize the issue.
> > ;-)
>
> I wrote an email to peer...@mcbone.net (I found it in their AS record at RIPE)

I just got an answer from them that the issue is fixed.
Thanks to everyone!

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] freenet.de routing issues anyone? (Cloudflare-OVH issue?)

[Stefano Bagnara via mailop]

On Fri, 8 Mar 2024 at 17:18, Tobias Fiebig via mailop  wrote:
> Moin,
> to get a bit back to the networking part of things...

:-)

> Poking a few people, this looks like a return path issue on Freenet's
> side; So they likely fnorded something on their side.
> Guess the only way to get this fixed is for them to realize the issue.
> ;-)

I wrote an email to peer...@mcbone.net (I found it in their AS record at RIPE)

I also did some tests here:
https://bgp.he.net/traceroute/

I put in the first field 194.97.8.138 (freenet NS) or one of my IPs at OVH
Then in the second field I put AS13335 (cloudflare) and select one of
the US probes.

The traceroute to my IP works, while the traceroute to 194.97.8.138
doesn't work.
This test does not even involve OVH, so I guess the OVH issue is just
because OVH route traffic for freenet through Cloudflare.
This is not even a generic Cloudflare-Freenet routing issue as from my
office connection (italy) my traceroute to 194.97.8.138 works even if
it goes throught Cloudflare, too.

BTW my netwoking knowledge is very low, so I don't know if this helps
identifying the issue.

> So if somebody can poke netops of AS5430,...
> Will try posting to denog to see if that helps.

Thank you!
Stefano
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] freenet.de routing issues anyone? (Cloudflare-OVH issue?)

[Stefano Bagnara via mailop]

Well,

I undestand you all hate OVH, but this really doesn't look like an
intended block.

I tested that when I log to my @freenet.de email I am not able to
write emails to any domain whose DNS are hosted by OVH. I know plenty
of italian companies whose domain zone is at OVH: even if their email
is at Google Workspace or somewhere else they currently cannot receive
emails from @freenet.de and you are telling me this is something
freenet.de done by purpose beucase they didn't want OVH spam? I'll
believe that once a freenet.de people will confirm it.

Considering OVH is the biggest registar in europe they are not
delivering email to most european domains.

So, if they blocked the whole OVH ASN at their SMTP server I could
even get that (even if I'm not aware of anyone else doing that), but I
really don't believe they blocked bidirectional routing between 2 ASN
just because freenet thinks OVH is spammy. We hardly see a similar
block when there is a war between 2 countries.

Stefano

On Fri, 8 Mar 2024 at 14:49, Yuval Levy via mailop  wrote:
>
> On 2024-03-08 07:48, Stefano Bagnara via mailop wrote:
> > On Fri, 8 Mar 2024 at 13:04, Mark Alley  wrote:
> >> Have you considered they may be blocking OVH ASNs on their firewall?
> >
> > Well, blocking the whole ASNs even to their NS sounds something very
> > unexpected.
>
> Extreme, yes. Unexpected? I disagree.  It is just another logical
> escalation step towards the inevitable, but nothing new.  Think of a
> collision between the internet's echo chambers and the Great Firewall:
> one side wants to control what the other side receives; and the other
> side wants to control what it does not receive.
>
> Simple Venn diagram.  When the intersection between the two circles
> (agreement on what both sides want to send/receive) has less net value
> than one of the two separate half-moons, the concerned side may as well
> block the whole ASN: the cost of sacrificing the intersection is lower
> than the benefit from allowing the communication less the
> filtering/sanitation cost.
>
> Once one side decides that it gets less benefits than cost from the
> communication, the other side has three strategic choices:  giving more
> value; causing less cost; or accepting the disconnect.  They are now at
> the accepting the disconnect, waiting to see who blinks first.  If
> no-one blinks, the disconnect becomes permanent.
>
> The problem is compounded by aggregation on the two sides: well behaved
> senders will put pressure on their side; the rats may abandon ship and
> raid the next ISP with weak policies.  Affected recipients will put
> pressure on their side to remove the filter.  The question is where
> those pressures will burst.  My hope is that someone at OVH will wake up
> and mop up the neighborhood that they control.
>
> Personally, I am still looking for the ideal firewall: block all ASNs
> unless permitted.  And even after that, the next battlefields are
> already in sight: wireless network traversal.
>
> Yuv
> ___________
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop



-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] freenet.de routing issues anyone? (Cloudflare-OVH issue?)

[Stefano Bagnara via mailop]

On Fri, 8 Mar 2024 at 13:04, Mark Alley  wrote:
> Have you considered they may be blocking OVH ASNs on their firewall?

Well, blocking the whole ASNs even to their NS sounds something very
unexpected. This mean any service (not only email) that is hosted in
OVH (in europe is the biggest provider) thinks their domains don't
even exists.
Also, freenet.de users are not able to write emails to anyone having
the DNS hosted at OVH (millions of domains): sounds like burning your
house to protect it from thieves :-D

Seems like AS5430 and AS16276 are not talking at all, but I don't know
how confirm it and how to check where is the issue in more detail.

> Their NS and zone seems resolvable and reachable from pretty much everything 
> else on the internet according to DNSchecker.org.

Here you can see their NS IP is not reachable from 7 on 30 location
being tested from western europe:
https://www.host-tracker.com/en/ic/3/189c2804-114d-4be7-94e5-716f131bc458

So, I think the issue is more on freenet side than OVH side, but I'd
need someone who knows or have powers to check.

Now I also wrote an email to the noc/peer emails for both ASN.
Stefano

> On Fri, Mar 8, 2024, 5:54 AM Stefano Bagnara via mailop  
> wrote:
>>
>> Hi,
>>
>> I'm experiencing routing issues to freenet.de MX since almost 3 days.
>>
>> I can't even lookup the domain as I cannot reach their NS, but the
>> same happens even if I try to ping their email server IP address:
>>
>> 194.97.8.138
>> 195.4.92.217
>>
>> From my servers @OVH they are not reachable at all.
>>
>> I checked the IPs at https://check-host.net/check-ping and I see both
>> IP pings from most places but a netherland one, hong kong and 4
>> russians sources (by comparison my own IPs are reachable from all of
>> those sources).
>>
>> Failing traceroutes from check-host.net and from my IPs stuck at a
>> Cloudflare IP:
>>
>> # traceroute 194.97.8.138
>> traceroute to 194.97.8.138 (194.97.8.138), 30 hops max, 60 byte packets
>>  1  MYIP  0.373 ms  0.484 ms  0.590 ms
>>  2  10.17.50.74 (10.17.50.74)  0.356 ms 10.17.50.72 (10.17.50.72)
>> 0.396 ms  0.458 ms
>>  3  10.73.17.68 (10.73.17.68)  0.101 ms 10.73.16.116 (10.73.16.116)
>> 0.107 ms 10.73.17.70 (10.73.17.70)  0.134 ms
>>  4  10.95.64.142 (10.95.64.142)  1.027 ms 10.95.64.156 (10.95.64.156)
>> 0.424 ms 10.95.64.136 (10.95.64.136)  0.421 ms
>>  5  par-gsw-sbb1-nc5.fr.eu (54.36.50.228)  3.949 ms  3.825 ms  3.821 ms
>>  6  10.200.2.85 (10.200.2.85)  4.079 ms 10.200.2.77 (10.200.2.77)
>> 71.136 ms  71.123 ms
>>  7  * * *
>>  8  172.71.120.4 (172.71.120.4)  4.689 ms 141.101.67.52
>> (141.101.67.52)  4.538 ms  4.578 ms
>>  9  172.71.133.105 (172.71.133.105)  3.842 ms 172.71.129.237
>> (172.71.129.237)  4.226 ms 172.69.187.98 (172.69.187.98)  4.214 ms
>> 10  172.71.133.23 (172.71.133.23)  5.352 ms 172.71.117.70
>> (172.71.117.70)  4.631 ms 172.71.121.67 (172.71.121.67)  4.512 ms
>> 11  * * *
>> 12  * * *
>> 13  * * *
>>
>> I thought it was a peering issue, but 3 days should be enough for
>> someone to detect and fix it.
>>
>> It doesn't look like a blacklisting issue as I cannot even query their
>> authoritative NS and I can't do that even from IPs that never sent
>> emails.
>>
>> I also checked OVH looking glass and they fail routing to freenet from
>> all of their DCs:
>> https://lg.ovh.net/traceroute/sgp+vin+sbg+bhs+hil+rbx+lim+bom+gra+waw+syd1+eri/ipv4?q=194.97.8.138
>>
>> I also tried using OVH hosted email to write an email to a freenet.de
>> domain and it resulted in a "Domain not found" error, so to confirm
>> the whole OVH network can't reach the freenet.de NS.
>>
>> I opened a ticket to OVH but they closed it telling me the traceroute
>> show the problem in outside their network (last working hop is a
>> cloudflare IP).
>>
>> Peering/routing is not my field, so I'm looking for other people with
>> problems sending emails to freenet.de and for suggestions on how/who
>> to contact to fix the issue (maybe I should look for an NOC-op mailing
>> list?) .
>>
>> Stefano
>>
>> --
>> Stefano Bagnara
>> Apache James/jDKIM/jSPF
>> VOXmail/Mosaico.io/VoidLabs
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://list.mailop.org/listinfo/mailop



-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] freenet.de routing issues anyone? (Cloudflare-OVH issue?)

[Stefano Bagnara via mailop]

On Fri, 8 Mar 2024 at 13:17, Marco Moock  wrote:
> Can you access their website on freenet.de from OVH?

No. I can't even reach their NS from OVH network.
So I can't resolve www.freenet.de: but if I try with the IP, then I
can't ping it.

> > From my servers @OVH they are not reachable at all.
>
> OVH is known to host spammers. Maybe they blocked the entire AS in
> their firewall.

I know, but I don't think this is the case. If I go to my free
@freenet.de inbox I can't write email to any recipient having their
DNS hosted at OVH because of this connection issue between the 2 ASN.
E.g. from my @freenet.de inbox I cannot write to my email address
@bago.org  because my NS is at OVH (while my email is at Google
Workspace).

So, if they did it by purpose because of spam I guess they blocked a
bit too much :-)

> > I opened a ticket to OVH but they closed it telling me the traceroute
> > show the problem in outside their network (last working hop is a
> > cloudflare IP).
>
> That is something OVH indeed can't fix.

Of course it if is a blacklisting it is not something OVH can fix (or
at lease, not easily).
But if the issue is unwanted or a peering issue maybe someone can do something!

> Maybe ask their postmaster from a public freemail service like gmx or
> gmail.

I wrote to postmas...@freenet.de too as not only they are not able to
receive from OVH but they are not able to delivery to any domain with
the DNS or email servers in the OVH network.

The fact that they NS can't see each other let me think this is not
something done by purpose, but I don't know how to investigate it to
understand how is responsible for the issue and who can fix it.

Stefano

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] freenet.de routing issues anyone? (Cloudflare-OVH issue?)

[Stefano Bagnara via mailop]

Hi,

I'm experiencing routing issues to freenet.de MX since almost 3 days.

I can't even lookup the domain as I cannot reach their NS, but the
same happens even if I try to ping their email server IP address:

194.97.8.138
195.4.92.217

From my servers @OVH they are not reachable at all.

I checked the IPs at https://check-host.net/check-ping and I see both
IP pings from most places but a netherland one, hong kong and 4
russians sources (by comparison my own IPs are reachable from all of
those sources).

Failing traceroutes from check-host.net and from my IPs stuck at a
Cloudflare IP:

# traceroute 194.97.8.138
traceroute to 194.97.8.138 (194.97.8.138), 30 hops max, 60 byte packets
 1  MYIP  0.373 ms  0.484 ms  0.590 ms
 2  10.17.50.74 (10.17.50.74)  0.356 ms 10.17.50.72 (10.17.50.72)
0.396 ms  0.458 ms
 3  10.73.17.68 (10.73.17.68)  0.101 ms 10.73.16.116 (10.73.16.116)
0.107 ms 10.73.17.70 (10.73.17.70)  0.134 ms
 4  10.95.64.142 (10.95.64.142)  1.027 ms 10.95.64.156 (10.95.64.156)
0.424 ms 10.95.64.136 (10.95.64.136)  0.421 ms
 5  par-gsw-sbb1-nc5.fr.eu (54.36.50.228)  3.949 ms  3.825 ms  3.821 ms
 6  10.200.2.85 (10.200.2.85)  4.079 ms 10.200.2.77 (10.200.2.77)
71.136 ms  71.123 ms
 7  * * *
 8  172.71.120.4 (172.71.120.4)  4.689 ms 141.101.67.52
(141.101.67.52)  4.538 ms  4.578 ms
 9  172.71.133.105 (172.71.133.105)  3.842 ms 172.71.129.237
(172.71.129.237)  4.226 ms 172.69.187.98 (172.69.187.98)  4.214 ms
10  172.71.133.23 (172.71.133.23)  5.352 ms 172.71.117.70
(172.71.117.70)  4.631 ms 172.71.121.67 (172.71.121.67)  4.512 ms
11  * * *
12  * * *
13  * * *

I thought it was a peering issue, but 3 days should be enough for
someone to detect and fix it.

It doesn't look like a blacklisting issue as I cannot even query their
authoritative NS and I can't do that even from IPs that never sent
emails.

I also checked OVH looking glass and they fail routing to freenet from
all of their DCs:
https://lg.ovh.net/traceroute/sgp+vin+sbg+bhs+hil+rbx+lim+bom+gra+waw+syd1+eri/ipv4?q=194.97.8.138

I also tried using OVH hosted email to write an email to a freenet.de
domain and it resulted in a "Domain not found" error, so to confirm
the whole OVH network can't reach the freenet.de NS.

I opened a ticket to OVH but they closed it telling me the traceroute
show the problem in outside their network (last working hop is a
cloudflare IP).

Peering/routing is not my field, so I'm looking for other people with
problems sending emails to freenet.de and for suggestions on how/who
to contact to fix the issue (maybe I should look for an NOC-op mailing
list?) .

Stefano

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] tiscali.it/tiscalinet.it reject RFC821 FROM domain as a CNAME because "domain does not have neither a valid MX or A record"

[Stefano Bagnara via mailop]

On Thu, 29 Feb 2024 at 12:09, Benny Pedersen via mailop
 wrote:
> > I think I wrote here too early: from further investigation seems like
> > the issue has gone and now those emails are not refused anymore.
>
> https://totaluptime.com/kb/cname-and-mx-for-the-same-host-name/
>
> dont use cname for email or even mx

Why?
The page you reported is correct as you cannot have CNAME and MX for
the same host, but I don't need CNAME and MX on the same host because
the spec cleary say that the domain can be a CNAME and in that case
you have to follow the CNAME before looking for the MX records. This
is the main reason CNAMEs exists: isn't it?

The opposite way, an MX pointing to a CNAME, is invalid according to
the SPEC, but that's another thing.

If you have RFC pointers about this "dont use cname for email or even
mx" I'd be happy to double check this and be corrected.

From https://datatracker.ietf.org/doc/html/rfc5321
2.3.5.  Domain Names
> For example, a domain may refer to an alias (label of a
> CNAME RR) or the label of Mail eXchanger records to be used to
> deliver mail instead of representing a host name.
> [...]
> In other words, names that can
> be resolved to MX RRs or address (i.e., A or ) RRs (as discussed
> in Section 5) are permitted, as are CNAME RRs whose targets can be
> resolved, in turn, to MX or address RRs.

So, not only they are not prohibited by the spec, but they are
explicitly permitted.

Do you understand something different from RFC5321? (I'm not a native
english speaker, but "as are CNAME RRs whose targets can be resolved,
in turn, to MX or address RRs" seems pretty straightforward).

Of course I could stop using the CNAMEd domain and use my shared
domain for all of my customers but this way I'd loose SPF alignment so
I refrain from doing that because of some uncompliant receivers and
subdomain delegation is not something 99% of my users/customers would
be able to do.

> and lastly cname breaks dnssec, dont do this, is tlsa not something you
> care about ?

I only receive bounces to those addresses, TLS is good enough. The
real replies are sent to domains not using CNAMEs.

Stefano

--
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] tiscali.it/tiscalinet.it reject RFC821 FROM domain as a CNAME because "domain does not have neither a valid MX or A record"

[Stefano Bagnara via mailop]

Well,

I think I wrote here too early: from further investigation seems like the
issue has gone and now those emails are not refused anymore.

According to the logs the issue lasted around 5 hours from 28/02/2024 07:00
CET to 28/02/2024 11:40 CET.

I had no answer from their postmaster, so I don't know if they simply found
the new rule was too aggressive or if it was a test and they will enable
the rule in future.

Stefano

On Thu, 29 Feb 2024 at 10:00, Stefano Bagnara  wrote:

> Hi,
>
> we are an ESP (a very small italian alternative to Mailchimp).
>
> Today an italian mailvox provider started refusing our emails with this
> message
> > 550 5.1.0  sender rejected:
> domain does not have neither a valid MX or A record
>
> The "e.#customerdomain" is a CNAME record that points to app.mailvox.it
> and app.mailvox.it has both A and MX records.
>
> I guess Tiscali is checking only the A and MX records for the sending
> domain without following the CNAMEs: in many years this is the first time I
> see something similar and I thought that many services sending email use a
> CNAME like us as the alternative (zone delegation) is a lot more complex to
> be setup.
>
> I just wrote email to Tiscali postmaster to understand if they will
> consider this "a bug in the new feature" or a "feature of the new feature",
> but in the mean time I wanted to share the issue as I think other senders
> use the same CNAME solution.
>
> We use that CNAME host in order to align the SPF authentication of emails
> sent by our customers but our email are also DKIM aligned, so I could
> simply use @app.mailvox.it instead of the customer CNAME in the
> return-path and emails would still pass DMARC via DKIM.
>
> Do you know other receivers refusing emails because the sender (smtp mail
> from) domain is a CNAME?
>
> --
> Stefano Bagnara
> Apache James/jDKIM/jSPF
> VOXmail/Mosaico.io/VoidLabs
>


-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] tiscali.it/tiscalinet.it reject RFC821 FROM domain as a CNAME because "domain does not have neither a valid MX or A record"

[Stefano Bagnara via mailop]

Hi,

we are an ESP (a very small italian alternative to Mailchimp).

Today an italian mailvox provider started refusing our emails with this
message
> 550 5.1.0  sender rejected:
domain does not have neither a valid MX or A record

The "e.#customerdomain" is a CNAME record that points to app.mailvox.it and
app.mailvox.it has both A and MX records.

I guess Tiscali is checking only the A and MX records for the sending
domain without following the CNAMEs: in many years this is the first time I
see something similar and I thought that many services sending email use a
CNAME like us as the alternative (zone delegation) is a lot more complex to
be setup.

I just wrote email to Tiscali postmaster to understand if they will
consider this "a bug in the new feature" or a "feature of the new feature",
but in the mean time I wanted to share the issue as I think other senders
use the same CNAME solution.

We use that CNAME host in order to align the SPF authentication of emails
sent by our customers but our email are also DKIM aligned, so I could
simply use @app.mailvox.it instead of the customer CNAME in the return-path
and emails would still pass DMARC via DKIM.

Do you know other receivers refusing emails because the sender (smtp mail
from) domain is a CNAME?

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Google rate limiting (UnsolicitedRateLimitError) for DKIM domain

[Stefano Bagnara via mailop]

On Fri, 16 Feb 2024 at 05:02, Evan Burke  wrote:

> It sounds like you're looking for a technical solution to a non-technical
> problem. This bounce code is quite rare, occurring for a fraction of a
> percent of the senders in my dataset. When it happens, it's a pretty strong
> sign the sender has a spam problem and needs to do some cleanup; adding
> rate limiting on your end won't change that.
>

No, your conclusions don't match my experience. It's weird somehow people
think the only cause for issues is spam :-)

Turns out the issue occours also to very good senders the first time they
authenticate their flow with their own domain, so the first time their
email pass from being signed with the ESP dkim to being signed with both
the ESP dkim and their own domain dkim (and being aligned).

So, it is not about unsolicited, but about "new flow" that Google does not
recognize (they probably don't get the double dkim signature to keep track
of the reputation in this change).

In fact the very same senders after a first time they get this error starts
sending without any issue: if it was about "a spam problem" the issue would
occour every time (or multiple times).

This is happening to us a lot because in the past months (after the
Yahoogle announce) we forced many of our customers in the 3-20K daily email
to authenticate so to pass DMARC. Previously they passed SPF and DKIM but
with a shared ESP domain, and not DMARC because there was no alignment, but
this worked fine (and still works fine, even for big senders, even if we
don't know how long: maybe this is because of the established good
reputation of our shared domain).

Considering the error from Google is not recognized as "special" our mta
retries sending to every google mx every 10 minutes and the whole email
(the error occours at ".") is transmitted 5 times per attempt.
So sometimes a single email is transmitted hundreds of times before it
finally gets delivered.

We also have indicators that even if the emails are delayed for hours at
the end they land the inbox and not the spam folder (open rates at gmail
are in the 40%).

Now we implemented a special MTA code that will recognize the specific
error and will delay for 1 hour every email with the same auth domain of
the email that received the error and we are fine: this way we still have
delays in sending that email flow, but we have almost zeroed
retransmissions (temp fails): this means many millions temp fail. And it
was a technical solution to a technical problem :-)

Also, Google acknowledged the missing domain indication in the refuse
message is not expected: who knows, maybe the fact they are not able to
handle the reputation transition from the shared DKIM to the additional
sender dkim is somehow related to this. Another technical problem.

Stefano


> On Tue, Feb 13, 2024 at 9:30 AM Stefano Bagnara via mailop <
> mailop@mailop.org> wrote:
>
>> On Tue, 13 Feb 2024 at 18:09, Matus UHLAR - fantomas 
>> wrote:
>>
>>> On 05.02.24 14:56, Stefano Bagnara via mailop wrote:
>>> >we are a small ESP and every email sent from our system has SPF+DKIM
>>> >authentication from our system and most email also have a second DKIM
>>> >signature (one signature with our domain, one with the domain of the
>>> >sender).
>>>
>>> is bago.org that domain?
>>>
>>
>> No, it's not :-) bago.org is my personal domain and does not send bulk
>> emails.
>>
>> A Google person already contacted me and identified the logs with the
>> missing dkim domain indication. I guess they consider it (the missing
>> domain indication in the error) a bug but I had no updates since then.
>>
>> Considering the email are signed with 2 different DKIM signatures they
>> told me which one the error is about, and it is the "customer one" and this
>> is enough for me.
>>
>> Unfortunately when I move a customer from "not authenticated" to
>> "authenticated" seems like Google is not able to recognize the consistent
>> DKIM signature on my own domain and starts rate limiting the new additional
>> DKIM signature for the customer. This is creating delay issues for some
>> customer in the first days after the authentication, but I understood
>> there's nothing I can do to improve this.
>>
>>
>>> - it does not have DMARC, perhaps this is you problem?
>>>
>>
>> No
>>
>> - it has some redundant SPF records:
>>>
>>
>> I'm not aware of issues with redundant SPF records, as long as I stay in
>> the 10 lookup: what are you talking about?
>>
>>
>>> I'm just not sure if I should advise you to drop
>>> "include:spf.mailvox".it or
>>&

Re: [mailop] Google rate limiting (UnsolicitedRateLimitError) for DKIM domain

[Stefano Bagnara via mailop]

On Tue, 13 Feb 2024 at 18:09, Matus UHLAR - fantomas 
wrote:

> On 05.02.24 14:56, Stefano Bagnara via mailop wrote:
> >we are a small ESP and every email sent from our system has SPF+DKIM
> >authentication from our system and most email also have a second DKIM
> >signature (one signature with our domain, one with the domain of the
> >sender).
>
> is bago.org that domain?
>

No, it's not :-) bago.org is my personal domain and does not send bulk
emails.

A Google person already contacted me and identified the logs with the
missing dkim domain indication. I guess they consider it (the missing
domain indication in the error) a bug but I had no updates since then.

Considering the email are signed with 2 different DKIM signatures they told
me which one the error is about, and it is the "customer one" and this is
enough for me.

Unfortunately when I move a customer from "not authenticated" to
"authenticated" seems like Google is not able to recognize the consistent
DKIM signature on my own domain and starts rate limiting the new additional
DKIM signature for the customer. This is creating delay issues for some
customer in the first days after the authentication, but I understood
there's nothing I can do to improve this.


> - it does not have DMARC, perhaps this is you problem?
>

No

- it has some redundant SPF records:
>

I'm not aware of issues with redundant SPF records, as long as I stay in
the 10 lookup: what are you talking about?


> I'm just not sure if I should advise you to drop "include:spf.mailvox".it
> or
> replace "include:spf.void.it" with "include:_spf.google.com"
>

No, I need that because spf.void.it may change in future.


> note that void.it also does not have DMARC and mailvox.it, while having
> SPF record for "spf.mailvox.it" does not have SPF for "mailvox.it".
>

Everything is expected.
mailvox.it does not send emails, only subdomains of mailvox.it sends email
and they have SPF records.

BTW none of those domains are involved in the issue I have with google :-D

And here are my attempt to answer my own questions:

> My questions:
> 1) is it expected that the error does not report the DKIM domain but only
> [ 36]?
>

It is a bug from Google.


> 2) how much is the "rate limit"? Does the rejected attempt count in this
> rate?
>

Starts as low as 1000/2000 emails per hour and looks like an hourly limit.


> 3) when, how often, how long does Google expects we retry the delivery
> after a 421-4.7.28 ?


I don't know but I changed the retry schedule for those flows so to wait 1
hour when I see that error.
I also think this is not about "Unsolicited rate" but simply about "rate
limiting" a dkim domain they don't recognize: it is unfortunate that they
don't keep trusting the other DKIM domain when they see 2 DKIM signatures
and one is well known to them, but given this seems to happen once per
customer we'll work around it.

Stefano


>
>
> >Since the past november we started seeing some UnsolicitedRateLimitError
> >temporary error and while some of them refer to an SPF domain ( "... from
> >your SPF domain [$domain$  35] ..." ) we also see a lot of "... from
> >your DKIM domain [  36]. ..." where no domain is in brackets, but only
> >the number 36.
>
> Google started rolling increased requirements since last year, perhaps
> they applied
> stricter requirements for your domain sooner.
>
>
> >The email being tempfailed are signed with multiple keys for multiple
> >domains, so I don't know what to "rate limit" (and how).
> >
> >Here is the full error received at the "." after sending the full body:
> >> 421-4.7.28 Gmail has detected an unusual rate of unsolicited mail
> >originating
> >> 421-4.7.28 from your DKIM domain [  36]. To protect our users from
> >spam,
> >> 421-4.7.28 mail sent from your domain has been temporarily rate limited.
> >For
> >> 421-4.7.28 more information, go to
> >> 421-4.7.28
> https://support.google.com/mail/?p=UnsolicitedRateLimitError
> >to
> >> 421 4.7.28 review our Bulk Email Senders
> >
> >Given it is a temporary failure our system keeps retrying very often,
> >resending the full message dozens times before it's accepted.
> >
> >Our Google Postmaster Tools (for our main domain signing every email)
> >doens't show anything problematic:
> >- Spam rate is < 0.2%
> >- IP reputation good for every IP
> >- Domain reputation is good
> >- "Feedback Loop" is completely empty (we have a token for each sender but
> >our senders are small: what's the volume required to show up her

[mailop] Google rate limiting (UnsolicitedRateLimitError) for DKIM domain

[Stefano Bagnara via mailop]

Hi all,

we are a small ESP and every email sent from our system has SPF+DKIM
authentication from our system and most email also have a second DKIM
signature (one signature with our domain, one with the domain of the
sender).

Since the past november we started seeing some UnsolicitedRateLimitError
temporary error and while some of them refer to an SPF domain ( "... from
your SPF domain [$domain$  35] ..." ) we also see a lot of "... from
your DKIM domain [  36]. ..." where no domain is in brackets, but only
the number 36.

The email being tempfailed are signed with multiple keys for multiple
domains, so I don't know what to "rate limit" (and how).

Here is the full error received at the "." after sending the full body:
> 421-4.7.28 Gmail has detected an unusual rate of unsolicited mail
originating
> 421-4.7.28 from your DKIM domain [  36]. To protect our users from
spam,
> 421-4.7.28 mail sent from your domain has been temporarily rate limited.
For
> 421-4.7.28 more information, go to
> 421-4.7.28  https://support.google.com/mail/?p=UnsolicitedRateLimitError
to
> 421 4.7.28 review our Bulk Email Senders

Given it is a temporary failure our system keeps retrying very often,
resending the full message dozens times before it's accepted.

Our Google Postmaster Tools (for our main domain signing every email)
doens't show anything problematic:
- Spam rate is < 0.2%
- IP reputation good for every IP
- Domain reputation is good
- "Feedback Loop" is completely empty (we have a token for each sender but
our senders are small: what's the volume required to show up here?)
- Authentication is 100% for SPF/DKIM/DMARC
- Cryptography is 100% TLS
- Delivery errors is shaky, most days is zero, but sometimes is 80%,
because of the tempfails above

My questions:
1) is it expected that the error does not report the DKIM domain but only
[ 36]?
2) how much is the "rate limit"? Does the rejected attempt count in this
rate?
3) when, how often, how long does Google expects we retry the delivery
after a 421-4.7.28 ?

Stefano

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Reaching out to GMAIL

[Stefano Bagnara via mailop]

On Tue, 21 Nov 2023 at 12:54, Ralf Hildebrandt via mailop
 wrote:
> We're running the postfix-users ML on list.sys4.de, and all over a
> sudden we're being tempfailed by GMAIL:

I saw something similar happening on a couple of my IPs recently. I
thought Google is slowly applying more restrictive rules/enforcement:
in my case the block persisted for few hours each time.
What's your abuse rate on the Postmaster Tools?

Maybe this is related to an abuse rate over 0.3%:
https://support.google.com/mail/answer/81126?visit_id=638361648208381724-1833007315=UnsolicitedRateLimitError=1#spam-rate=%2Crequirements-for-sending-or-more-messages-per-day
-
Spam rate
- Regularly monitor your domain's spam rate in Postmaster Tools.
- Aim to keep your spam rate below 0.10%.
- Avoid a spam rate of 0.30% or higher, especially for any sustained
period of time.
-

> 421-4.7.28 Gmail has detected an unusual rate of unsolicited mail. To protect
> 421-4.7.28 our users from spam, mail has been temporarily rate limited. Please
> 421-4.7.28 visit
> 421-4.7.28 https://support.google.com/mail/?p=UnsolicitedRateLimitError to
> 421 4.7.28 review our Bulk Email Senders Guidelines. 
> s8-20020adfea8800b0032fba209e8esi6123538wrm.543 - gsmtp (in reply to end 
> of DATA command)
>
> SPF, DKIM, DMARC, douoble-opt-in, valid forward and reverse DNS
> records are all in place, and it's been working ok for quite some time
> -- so it's a bit unclear what has changed here or what caused the
> block...
>
> And since it's the postfix-users mailinglist, we're dead sure it's not
> spam we're sending!

Check in the Postmaster Tools as, even if it's hard to accept/believe,
people report as abusive even emails with tickets they just bought on
some online store.

Stefano
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: PSL: SOA record per subdomain required?!

[Stefano Bagnara via mailop]

On Tue, 9 May 2023 at 04:10, John Levine  wrote:
> It appears that Stefano Bagnara via mailop  said:
> >Sounds like our standard senders using @e.example.com domain in their
> >RFC5321 are able to deliver to Yahoo while italian municipalities
> >using, e.g.,  @e.comune.bardolino.vr.it (so 2 more levels) don't work.
>
> Well, yeah, because vr.it is in the PSL.  Same exact problem.

What would be the fix for this case? Where should we try to add the
missing SOA record? (I'm not sure we can do that, but at this time I
don't even get which SOA record should be added to which host in order
to fix the issue).

#1 host -t soa e.comune.bardolino.vr.it
e.comune.bardolino.vr.it is an alias for app.mailvox.it.
#2 host -t soa app.mailvox.it
app.mailvox.it has no SOA record
#3 host -t soa comune.bardolino.vr.it
comune.bardolino.vr.it has SOA record dns.technorail.com.
hostmaster.comune.bardolino.vr.it. 1 86400 7200 2592000 3600
#4 host -t soa bardolino.vr.it
bardolino.vr.it has no SOA record
#5 host -t soa vr.it
vr.it has no SOA record
#6 host -t soa it
it has SOA record dns.nic.it. hostmaster.nic.it. 2023050909 10800 900
604800 3600

I guess it is not the missing SOA at #2 because all of our senders
share that step and most of them show no issues.
So maybe the issue are the missing SOA at #4/#5, but this would be out
of control by me or my customer (che municipality of Bardolino).

Maybe Yahoo has to whitelist us somehow? I wrote them.

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: Yahoo: SOA record per subdomain required?!

[Stefano Bagnara via mailop]

On Mon, 8 May 2023 at 20:50, Marcel Becker via mailop  wrote:
> I can't speak for the Yahoo of over a decade ago, but I can assure you that 
> the Yahoo of today will respond and try to help you if you actually reach out 
> to us having a problem delivering your mail people actually want.

We think we see this SOA issues for our italian municipalities senders.

Sounds like our standard senders using @e.example.com domain in their
RFC5321 are able to deliver to Yahoo while italian municipalities
using, e.g.,  @e.comune.bardolino.vr.it (so 2 more levels) don't work.
(I have a lot of cases confirming both working and not working cases:
the non working are all the "*.comune.*.[a-z][a-z].it").

RFC5322 domain, instead, is @example.com / @comune.bardolino.vr.it
(no "e." subdomain).

How should we contact you? Am I expected to fill
https://senders.yahooinc.com/contact#sender-support-request using the
data of my customer?

In both cases (working and not-working) the "e" subdomain is a simple
CNAME to an host in A/MX records: where I am expected to add a SOA
record?

In both cases SOA queries to the "e" subdomain will simply find the
CNAME to an host without a SOA while the SOA to the remaining domain
works.

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] T-Online is now really blocking messages from non-commercial and simliar senders

[Stefano Bagnara via mailop]

On Wed, 19 Oct 2022 at 13:32, Heiko Schlittermann via mailop
 wrote:
> A given mailhost (ran privately for smaller entities) can't send
> messages to T-Online anymore.
>
>   554 IP=168.119.159.241 - A problem occurred. …

Do you get this error at the connection or after you transmitted the message?

If you get the error after the "DATA" and "." then maybe you just need
DKIM+DMARC compliance for your emails.

In this case look for an old thread here:
"DKIM+DMARC at t-online.de (Deutsche Telekom's ISP branche)" by
florian.kun...@telekom.de (Apr 6 2021)

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Timeouts to Microsoft?

[Stefano Bagnara via mailop]

Hi,

Since 4 hours we are experiencing slowness (e.g. connections timing
out, very slow responses), to Microsoft both sending to their SMTP and
reading via IMAP, from europe (checked from 4 different datacenters in
europe).

Do you see the same?

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DKIM+DMARC at t-online.de (Deutsche Telekom's ISP branche)

[Stefano Bagnara via mailop]

On Fri, 16 Apr 2021 at 11:45, Florian.Kunkel--- via mailop
 wrote:
> the requirements posted before only apply to ESPs (email service providers | 
> mass mailers | ... mailhosters).
> Mailing lists should not be concerned as far as I can tell from our stats.
> []
> that's the reason we didn't start with DMARC policy enforcement so far.
> it's to gamy to adhere the domain policy without regard of the source IP you 
> see the message from.

Hi Florian,

do you have any update about this DMARC enforcement "experiment" @t-online.de ?

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] USGOabuse.net?

[Stefano Bagnara via mailop]

On Thu, 30 Sept 2021 at 09:26, Thomas Walter via mailop 
wrote:

> I have just received an abuse report from USGOabuse.net regarding an
> incident that happened on July 6th and was resolved immediately:
>

I had an issue with usgoabuse, too, in past.

They first sent to our abuse@ email an FBL formatted abuse report. This was
about a single opt-in confirmation email that resulted to be unsolicited
(probably part of a distributed subscription bombing, but was only a single
email from our infrastructure). The email asked to simply ackknowledge the
issue otherwise they could have blocked the IP.

We did ack and we are sure no more emails have been sent to them, but the
next day they sent a new copy of the same abuse report and this time the
report said the IP was blacklisted.


> They want me to acknowledge the report by going to
> http://m.USGOabuse.net/_AbuseAck and ask for some strings. Otherwise
> "Repeated reports regarding the same source that are unacknowledged will
> eventually result in blacklisting" - which it already did according to
> the summary above?
>

I was not sure about what was happening and I wanted to understand if there
was a bigger issue I didn't identify, but the reports were from noreply
addresses, so I sent an email to ab...@usgoabuse.net ab...@usgo.net
ab...@usfamily.net and they promptly answered that they blacklisted my IP
because one of their recipient was victim of subscription bombing and
flooded by thousands of subscription bombing email and *one* of those
emails were from our network.

I suggested that I did not find fair to send 2 *automated* emails to an
abuse department, using noreply, asking for the abuse department to
acknowledge the issue and saying contrasting/confusing things (we may block
if the issue is not fixed => we blocked you anyway), expecially if the
abuse to be reported is a single COI request and not a
malware/virus/whatelse.

Months after that episode I received another similar abuse report from
them: I forwarded the report to our "FBL processing agent" but I didn't ack
it, as I found it was a waste of time.

Stefano

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Technical Contact to paddle.com mail platform operator?

[Stefano Bagnara via mailop]

On Mon, 5 Jul 2021 at 11:02, Benoît Panizzon via mailop
 wrote:
> We have a customer who orders software licenses via paddle.com
>
> He should get keys via Email. But they never arrive. I also don't see
> any trace of those emails in our logs.

Hi had an issue with missing email from them to me. No one was able to
fix it until I found the email were, in fact, delivered, but they were
delivered to a wrong email address (the first one the merchant sent to
paddle when they created my account and not the one I used through the
merchant when I bought) and the email were delivered in spam, so I
didn't see them in the wrong account.

When I found this I used GDPR rights to ask them what data they had
about my "old email address" (the one receiving the email) and they
answered my email address was not in their system, LOL. I sent them
the header of the email received 2 days before and they insisted that
they sent that email to another email address (the one that should
have receveid the email, in fact) but email headers don't lie.

So, I don't know, but maybe they do something weird with email
addresses updates, so maybe the email you're looking for have been
delivered to a different email address ;-)

My last 2 messages have been sent from Postmark (
mta197a-ord.mtasv.net. [104.245.209.197] and mta216a-ord.mtasv.net.
[104.245.209.216] ).

Stefano
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] protection.outlook.com refusing to accept mail with misleading temp error message

[Stefano Bagnara via mailop]

On Tue, 1 Jun 2021 at 21:39, John Levine via mailop  wrote:
> No, it's to deliver the mail that the users want. One point that bulk
> mailers often miss is that, while the recipients at large providers do
> not object to getting the bulk mail, they also do not really want it.

I received Microsoft Office 365 invoices in the Junk folder of my
untrained/verbatim Office 365 inbox, because of SmartScreen.
No one likes invoices, i guess...

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Registered @ Microsoft JMRP - blacklisted without feedback received

[Stefano Bagnara via mailop]

We recently saw that "S3150" on 3 IPs part of 3 larger netblocks.
For all of them we opened a ticket and they "mitigated the IP": I
tried collecting more info to no avail, of course :-( .

Weird thing is at least one of them has always been *green* on SNDS
and had not abuse reports at all in the recent months.
That IP is part of a 9IP shared pool, so sending the same emails of
the other neighbour IPs and it is the only one that was blocked with
that error.
That IP was a low volume IP (200-400 daily email) and I randomly
picked few emails from the days before the block and I have not been
able to identify spammy emails.

I asked in the ticket if they could give some hint about the issue as
I can't find spammy emails, I didn't receive abuses and SNDS says
everything was good before (and everything is still good for the twin
IPs) but they simply mitigated and ignored my questions.

So, +1 to your questions.

Stefano

On Tue, 11 May 2021 at 14:07, Benoit Panizzon via mailop
 wrote:
>
> Dear List
>
> One of our main smtp outbound ip addresses is blocked by microsoft.
>
> host outlook-com.olc.protection.outlook.com[104.47.10.33] said: 550 5.7.1
> Unfortunately, messages from [157.161.12.84] weren't sent. Please
> contact
> your Internet service provider since part of their network is on our
> block
> list (S3150). You can also refer your provider to
> http://mail.live.com/mail/troubleshooting.aspx#errors.
> [DB5EUR03FT006.eop-EUR03.prod.protection.outlook.com] (in reply to MAIL
> FROM command)
>
> I checked our JMRP entries. This IP is listed as one of our
> mailservers. The complaint rate is < 0.1% but it had 2 'trap' hits and
> is in status red.
>
> Our abuse desk email address is registered for the ARF feedback loop
> for the ip range in question.
>
> We usually get a lot of feedback loop emails, mostly false positives of
> Mirosoft users mixing up 'junk' with their trash folder or similar, or
> moving all their old mail to 'junk' causing an avalanche of complaints
> being sent. I opened several cases with Microsoft about this, but never
> got any solution offered (as a sidenote rant)
>
> But no, there were no complaints about: 157.161.12.84 received.
>
> Does anyone know, how to get hold of the emails that caused this
> blocking?
>
> Mit freundlichen Grüssen
>
> -Benoît Panizzon-



-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [EXTERNAL] Re: Registered @ Microsoft JMRP - blacklisted without feedback received

[Stefano Bagnara via mailop]

On Wed, 12 May 2021 at 05:08, Michael Wise via mailop  wrote:
> S3150 is throttling.
> Open a ticket and ask for a more realistic hourly/daily throttle limit.

Can you confirm?

This is weird because SMTP error is: "550 5.7.1 Unfortunately,
messages from [IP] weren't sent. Please contact your Internet service
provider since part of their network is on our block list (S3150). You
can also refer your provider to
http://mail.live.com/mail/troubleshooting.aspx#errors.
[DB8EUR05FT023.eop-eur05.prod.protection.outlook.com]"

The SNDS message in the "View IP status" was: "Blocked due to user
complaints or other evidence of spamming"

Also, the IP was unable to send a single message for days until the
mitigation and the message volume for the days before the block was
very low (<500 messages per day).

It really didn't look like "throttling", but the next time it will
happen I'll try that request to the support.

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [EXTERNAL] Re: Registered @ Microsoft JMRP - blacklisted without feedback received

[Stefano Bagnara via mailop]

On Tue, 11 May 2021 at 19:31, Michael Wise via mailop  wrote:
> JMRP doesn’t send every email reported as spam to the sender.
> Last I heard, it was 1 in 1,000 or some such.
> This is to prevent listwashing, as should be obvious.

But what about SNDS "Complaint rate" and "Trap hits"? Are they about
all of the reports you collect or about the 1/1000 you send via JMRP?

In my case there was nothing at all in SNDS  (green , complaint <0.1%,
no trap hits for every day in the SNDS history), but still I got that
S3150. I've been mitigated when I opened the ticket but I have no clue
what was the issue so I can't fix anything.

If you have abuses that you don't want to shared (and I understand the
listwashing issue) I would expect you to put the counters in SNDS
anyway: am I wrong?

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Anyone from Outlook domain here.

[Stefano Bagnara via mailop]

On Thu, 29 Apr 2021 at 11:14, vsai--- via mailop  wrote:
> Outlook is blocking mails that are auto-forwarded from my domain.

Open a ticket here:
http://go.microsoft.com/fwlink/?LinkID=614866

PS: email forwarding nowadays is a PITA and maybe there's no fix to
your issue but stop forwarding.

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Sendgrid is giving others anti-abuse/security advice? Wow!

[Stefano Bagnara via mailop]

On Thu, 11 Feb 2021 at 18:49, Rob McEwen via mailop  wrote:
> These questions! WOW! IS THIS FOR REAL? Don't get me wrong, I like Len 
> Shneyder
> and I think he's a good person TRYING to do the right thing - but - 
> considering what is coming
> FROM SendGrid in recent years, is this the right time to be giving OTHERS 
> anti-abuse/security
> advice? Just... wow! I think they should instead consider trying to "lead by 
> example".
> The world would certainly become a MUCH better place!
> https://martechseries.com/mts-insights/tech-bytes/len-shneyder-twilio-sendgrid/

I didn't read anti-abuse and security advices in the article.

He's just talking about how DMARC evolved and the role of social
engineering in phishing.

He's not even trying to let people guess Sendgrid is good at preventing abuses.

no "Wow" here :-)

Stefano

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Is it something to worry about?

[Stefano Bagnara via mailop]

On Thu, 21 Jan 2021 at 18:16, Jim Popovitch via mailop
 wrote:
> > Maybe you'll grasp the issue only when they will list Ramnode :-)
> > Or maybe you'll be happy to pay or to move to another ASN until they catch 
> > up...
>
> You seem to be under the assumption that uceprotect is just looking for
> providers to list.  I think, and I know, that Ramnode is a responsible
> hosting provider.  They take abuse report seriously, and act swiftly.
> If you read the details about the ASNs that uceprotect list, it's clear
> that those ASNs do not.

No assumptions here:
http://www.uceprotect.net/en/rblcheck.php?asn=3842
"ATTENTION Increased Listingrisk"

OVH was in "ATTENTION Increassed Listingrisk" until UCEPROTECT lowered
10 fold their thresholds, so I wouldn't bet you are safe there.
Let's say you chose an almost shady provider :-)

Stefano
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Is it something to worry about?

[Stefano Bagnara via mailop]

On Thu, 21 Jan 2021 at 17:37, Mary via mailop  wrote:
> Linode blocks port 25 on all new accounts/servers. You need to talk to them 
> and explain who and what you are, before they open it manually for you.

But this was not enough to prevent them being listed in level-3:
http://www.uceprotect.net/en/rblcheck.php?asn=63949

217 level-1 in the last 7 days on 510.000 IPs.

I see Oracle is in level-3 too:
http://www.uceprotect.net/en/rblcheck.php?asn=31898
267 level-1 in the last 7 days on 1.2 millions IPs.

I guess most small ASN are not in level-3 just because of the "at
least 10 level-1" requirement.

Stefano
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Is it something to worry about?

[Stefano Bagnara via mailop]

On Thu, 21 Jan 2021 at 15:04, Jim Popovitch via mailop 
wrote:

> > "Pay us for protection", when it really means "pay us or we'll [break
> > your knees|set your house on fire|break your windows...]" isn't
> > insurance, and can get you arrested.
>
> Neither of those situations describe the reality of what uceprotect is
> doing.  They are saying that if you choose to operate in a shady area,
> they will, for a payment, whitelist your address so that you can send
> email.  Historically, email delivery was always tied to knowing who the
> sender was.  This has been going on for decades, even with folks like
> Barracuda.  It's never been about the $$, it's always been about
> identifying the responsible party.
>

This make me think to the "First the came..." thing: saying that around 1
million OVH customers *chose* to operate in *shady area* is a strong
statement.

Maybe you'll grasp the issue only when they will list Ramnode :-)
Or maybe you'll be happy to pay or to move to another ASN until they catch
up...


Stefano
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] subscription bombing prevention best practices

[Stefano Bagnara via mailop]

On Wed, 20 Jan 2021 at 20:05, Simon Arlott via mailop 
wrote:

> On 20/01/2021 10:50, Stefano Bagnara via mailop wrote:
> > I'm looking for brainstorming and updated industry "standards" from
> people
> > handling outgoing SMTP services or ESP exporting APIs to "request
> > subscriptions" (confirmed opt-in).
>
> How about a web-based process to confirm opt-in?
>
> Domains could opt into it by a DNS TXT record providing the URL of a
> confirmation service. This would function something like OpenID and the
> result would be a confirmation or rejection of the subscription.
>

OpenID itself would already work, I guess: in fact some of our users
already skip the confirmation email using the "register with google"
function for @gmail.com users.

Of course a DNS method to let domains opt-in to such a generic system would
be cool, but unless we think 100% of domains will adopt openid we'll still
have the subscription bombing issue around, for every form not using this
"new method" and every recient on a domain not using this method.

So I like your proposal, but I was looking for best practices to deal with
what happens now: forms being abused to fill email inboxes of innocent
victims.

It would take time to be adopted but it would put an end to "enter your
> email address" forms accepting anything that is entered.
>

I think we'll be able to see something similar only if browsers directly
implement some kind of openid support to deal with user/profile management
more easily. Considering this is not happening for website authentication I
doubt the confirmed opt-in world will push this ;-)

Stefano
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] subscription bombing prevention best practices

[Stefano Bagnara via mailop]

Hi all,

I'm looking for brainstorming and updated industry "standards" from people
handling outgoing SMTP services or ESP exporting APIs to "request
subscriptions" (confirmed opt-in).

Not every website uses CAPTCHA and also webforms using CAPTCHA are being
abused as even reCAPTCHA have been cracked by some botnet.

So, we implemented per-recipient "antiflood" measures and sender
throttling, we implemented a distributed near-real-time "recipients black
list" in order to identify victims across our infrastructure ASAP and stop
the flow.

We also implemented some smart solution on the webforms we directly manage
with different CAPTCHAs optionally proposed depending on internal and
public blacklists of abusive IP/networks and webform filling behaviours:
this works fine, but this is only a part of the outgoing flow and we can't
do the same on transactional requests submitted via API or sent via
authenticated SMTP.

We require transactional email to provide us the IP of the user that
triggered the email, so we can use our blacklists for them, too, but in
this case we can't provide a CAPTCHA in an API or the SMTP conversation, so
balancing false positives and false negatives is harder.

The bigger the infrastructure the bigger the dataset of abuses adn the more
efficient this kind of blacklists works, that's why IP blacklists have been
made public and "shared", but I guess a "current subscription bombing
victims DNSBL" does not exists and is not even easy to think how it could
work at a global scale.

Of course one option is to get in touch with every single sender, as soon
as we recognize a single request as subscription bombing and explain them
how to change their website in order to protect it but this is a big PITA
considering most time they use CMS they don't even understand, and because
the user is multiple steps away from us (whitelabel services and
resellers), but before taking this path I preferred to ask here.

One of our transactional IPs have been recently blacklisted by one provider
because of a *single* "subscription confirmation request" transactional
email received by one of their recipients targeted by a subscription
bombing issue. The protections on our side didn't trigger as it was a
single request from a clean IP for a recipient we never seen before and
there was nothing suspicious in the request to decide to block it. I don't
care of that specific blacklisting, but I'd like to be responsible and
understand what most of us (postmasters) expect from each other in the real
world (where a system with 0 false-negatives does not exists).

How do you deal with this issue?

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Is it something to worry about?

[Stefano Bagnara via mailop]

On Wed, 20 Jan 2021 at 11:54, Jim Popovitch via mailop 
wrote:

> For me, it's "appreciate never seeing those emails".  I outright block
> level 2 and level 3, and high score level 1.  I've been doing that for
> years now and have never seen a reject log message that wasn't already
> listed in Zen, Sorbs, or Psbl.
>

If this was true then it would be pointless to use UCEPROTECT if you
already use Zen, Sorbs, Psbl ;-)

E.g: OVH is currently in UCEPROTECT level-3, I have a few IPs there, none
of them is in Zen, Sorbs, Psbl, but, of course, are in UCE L3 right now.

Stefano
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Automatic abuse reports from Simply.com

[Stefano Bagnara via mailop]

Hi all,

we received few automated abuse reports from Simply.com.

The abuse report is an email from "Simply.com abuse team <
abuse-rep...@robot.simply.com>"
with subject "Abuse report for #IPredacted# (#Providername# / #ASNUMBER#)"

> Hi
>
> This is a complaint regarding spam received from #IPredacted# /
#hostredacted#.
> Mail originating from this IP, has actively been marked as spam/junk by
the receiver.
>
> We ask that you take immediate action against the offending IP-address.
>
> For forensic purposes, the offending email is attached to this mail
(along with other
> report > formats). Below are some key headers from the mail:
>
> Date: #redacted#
> Message-Id: <#redacted#>
> From: <#redacted#>
> Return-path: <#redacted#>
>
> #IPredacted# has received degraded delivery-reputation as a result of the
report.

In one case the message terminated with a

> For good meassure, the List-Unsubscribe URL in the mail has already been
triggered by us.

The "weird" things are 2:

1) at least 2 abuses have been sent also to the abuse desk of a different
datacenter from the one from which the email have been sent. I'm not sure
but it seems they got in touch with the abuse desk of the datacenter
hosting the website connected to the return-path of the email (not even
it's MX, but the IN A, but maybe something else, I only have a couple of
sample to make my guess).
2) one of the abuses was reporting the transactional email confirming to
the recipient his unsubscription was completed, but the unsubscription have
been triggered programmatically by them: I guess that their user that
didn't unsubscribe from the email is surprised by the "unsubscription
confirmation" and report it as abusive.

I checked the logs and sounds like they automatically did a GET request to
the List-Unsubscribe url and the a POST request to the List-Unsubscribe url
via the "List-Unsubscribe-Post" protocol we support. I understand the ratio
of a similar behaviour but I was not expecting the list-unsubscribe or the
list-unsubscribe-post could be triggered without the recipient asking
explicitly from unsubscription.

Of course their server their rules, but I'd like to know if other abuse
desks started receiving this kind of automated simply.com reports and
what's your opinion about this practice.

In the end for (still under investigation) 2 emails sent to their users we
received like 8 abuse reports, some directly, some through the abusedesks
of our datacenter, some for the original email and some more for the
unsubscription confirmation email, so I'm guessing if your abuse desks are
flooded by this or there's something so bad about those 2 emails (again,
under investigation, I can't tell by looking at the content and I'm waiting
for answers from the sender).

Sounds like this kind of automation belongs to FBL streams, but I'm here to
hear your opinions!

Stefano

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] SNDS "No data for specified IPs on this date" for the last 3 days

[Stefano Bagnara via mailop]

for the past 3 days SNDS show "No data for specified IPs on this date":
does it work for you?
(I can see data for the previous days)

Stefano

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [EXTERNAL] Re: Attention Michael Wise - need your assistance

[Stefano Bagnara via mailop]

n%2Fmailman%2Flistinfo%2Fmailopdata=02%7C
>
> > 01%7Cmichael.wise%40microsoft.com%7C6e1b6be42d0e4b6d3cd708d80996a9b4%7
>
> > C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637269889983169342sda
>
> > ta=U2g2RpeOsMYj2HYPbeiBPe6BNt%2BzQIyafUSHNYLaQHo%3Dreserved=0
>
>
>
>
>
>
>
> --
>
> Al Iverson // Wombatmail // Chicago
>
> Song a day! 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.wombatmail.com%2Fdata=02%7C01%7Cmichael.wise%40microsoft.com%7C6e1b6be42d0e4b6d3cd708d80996a9b4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637269889983169342sdata=2G0X5pEAhqgQwHFRlFIwbK0utpnIE89Lt2AV4I0%2Bdzs%3Dreserved=0
>
> Deliverability! 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fspamresource.com%2Fdata=02%7C01%7Cmichael.wise%40microsoft.com%7C6e1b6be42d0e4b6d3cd708d80996a9b4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637269889983169342sdata=Iu%2Fpy3uZzW%2F2xTBOsvbCjQtM7QI41Hk7cqLXbYJQ%2Bog%3Dreserved=0
>
> And DNS Tools too! 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fxnnd.com%2Fdata=02%7C01%7Cmichael.wise%40microsoft.com%7C6e1b6be42d0e4b6d3cd708d80996a9b4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637269889983169342sdata=QamPS5ZXRqFrfzXbwKdYwEhVNZtZ2Y%2FC%2BjzDxG1PNIc%3Dreserved=0
>
>
>
> ___
>
> mailop mailing list
>
> mailop@mailop.org
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchilli.nosignal.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fmailopdata=02%7C01%7Cmichael.wise%40microsoft.com%7C6e1b6be42d0e4b6d3cd708d80996a9b4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637269889983169342sdata=U2g2RpeOsMYj2HYPbeiBPe6BNt%2BzQIyafUSHNYLaQHo%3Dreserved=0
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop



-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Which ESP forces double opt in?

[Stefano Bagnara via mailop]

On Mon, 8 Jun 2020 at 11:33, Laurent S. via mailop  wrote:
> Which ESP does 100% (double/confirmed) opt in?
>
> I am looking for an ESP that will, in every case, send a confirmation
> link without ever trusting their clients about the consent status of
> lists they import?

AFAIK no one.
You can find ESPs that are forcing confirmed opt-in for emails
collected using their forms (instead of allowing or defaulting to
single opt-in).
Some of them don't even require "consensus based mailings": many of
them require consent in their ToS but they trust the customer unless
they have something to not believe him.

> I am aware this means some recipients might never click the link and get
> another 2nd mail. I am also aware this doesn't block every abuse, as
> Laura mentioned (I've seen those too):

I'm not sure this would be a great idea as sending a "massive
single-opt in request" is anyway a massive email.
An opt-in request email should be sent only when the user just
compiled the form.

So, you have 3 kinds of lists:
1) spam lists: the ESP would send the opt-in email to all of them and
this would be spam anyway.
2) single-opt-in-lists: the ESP would send a massive email (the
confirmation request) and for some of them this will be spam for some
other ignoring the message this will mean stopping receiving something
they asked to receive)
3) confirmed opt-in lists: like #2 but only the bad parts.

IMHO
- if an ESP has a way to understand the customer will do spam then
they should not send anything, not even a reconfirm email.
- otherwise once they send their first email the ESP will collect some
data and usually detect a spammer sender better than sending a
reconfirm email.

If every ESP requested a reconfirmation email customers would be stuck
in their ESP and every ESP could increase prices 10x as customers will
never accept to reconfirm their whole already confirmed lists just
because they don't want to accept their new ESP prices. Spammers,
instead, would happily load their scraped/purchased lists to every
ESP, running a subscription bombing to their lists and using each ESP
against the parts that confirmed the opt-in on that specific sender.

Furthermore forcing COI is not enough for a real consent-based
mailing: the ESP should also require reconfirmations for every email
that has not been mailed for more than 6-12 months and maybe they
should also require reconfirmation when the sender email changes or
the contents for the messages are changed or the mailing frequence
changes (as consent is not just a "yeah, drop whatever you like in my
mailbox"). One of the worst customers we kicked for spam was in fact
using confirmed opt in but the users were not really asking him to
receive the emails he finally sent them. He did a lot of "win an ipad"
forms and then redirected the users to our COI forms: then he was
sending them car insurance or easy credit access or anything else.
Technically this may be COI, but without a real consent. So COI would
not solve ESP issues anyway. So if you think that enforcing COI will
give you a better reputation ESP then I'd reconsider this.

So, I'm a great COI fan (IMHO "single/unconfirmed opt-in" is almost
equal to "no opt-in"), but I'm not sure that expecting ESP to force
reconfirmation so to only send COI emails would really fix any issue.
I know you asked for a list and not a COI discussion, but I think/hope
the above explains why you probably won't find such a list.

Stefano

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] ItaliaOnLine (@libero.it, +) now interpreting DMARC p=none as p=quarantine

[Stefano Bagnara via mailop]

On Tue, 26 Nov 2019 at 14:30, Benjamin BILLON via mailop
 wrote:
> ItaliaOnline is rolling out new rules, including the necessity of having a 
> DMARC record (and also a valid DKIM signature), among other things.
> I believe those kind of delivery placement (on p=none) is a side effect of 
> what they're trying to do.

UPDATE: sounds like since yesterday everything came back to normal and
email are not marked as spam any more for a failed dmarc check with
p=none.
Now the DMARC header correctly says:
"X-IOL-DMARC: fail_monitor con il dominio msn.com"

So, I guess you were right and it was an unwanted side effect.

Thank you,
Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] ItaliaOnLine (@libero.it, +) now interpreting DMARC p=none as p=quarantine

[Stefano Bagnara via mailop]

On Tue, 26 Nov 2019 at 14:13, Paul Smith via mailop  wrote:
> On 26/11/2019 12:41, Stefano Bagnara via mailop wrote:
> > I don't know if ItaliaOnLine postmaster follow this list and if they
> > consider this new behaviour a feature or a bug, but I wanted to share
> > this finding/news with you.
> >
> > What do you think about this? Do you know other providers making this
> > "deliberate guess"?
>
> It's bad for an ISP to do that. 'p=none' is often used for the case of
> "we've just started using DMARC and don't know if we've got it set up
> correctly yet", so treating it as p=quarantine is going to lead to lots
> of false positives.
>
> On the other hand, if this is JUST for mail from msn.com, they may have
> decided that that domain is established enough that hopefully the admins
> know what they're doing, so may have an exception to treat mail FROM
> THAT DOMAIN as p=quarantine (similarly with gmail.com, which also has
> p=none)

My test confirmed it happens also with one of my own domains where I
activated p=none as a test.

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] ItaliaOnLine (@libero.it, +) now interpreting DMARC p=none as p=quarantine

[Stefano Bagnara via mailop]

Hi all,

We noticed that since 3 days, ItaliaOnLine is delivering to Junk every
email failing a DMARC check, even when the sender domain publish a
p=none rule.

You can check the "reason" in the headers:
"X-IOL-DMARC: fail_quarantine con il dominio msn.com"

This is expected for p=quarantine rules, but unexpected for p=none
rules, but this is happening for msn.com, gmail.com and less common
domains using p=none, too, whenever the DMARC check is failed.

I don't know if ItaliaOnLine postmaster follow this list and if they
consider this new behaviour a feature or a bug, but I wanted to share
this finding/news with you.

What do you think about this? Do you know other providers making this
"deliberate guess"?

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Hotmail delivery issues

[Stefano Bagnara via mailop]

On Sun, 17 Nov 2019 at 19:22, Jan-Philipp Benecke via mailop
 wrote:
> currently we've delivery problems to hotmail/outlook/... O365 looks good.
> SNDS shows us just red for all our IPs since end of September.
> We haven't changed anything neither some crappy mailings nor new spamming 
> customers.
> We've done, with our abuse department, also a random review of the mailings. 
> No results.
> Our complaint rate is below 0.1% and just a few spamtrap hits, but compared 
> to the sending amount this is minimal.

I never had confirmations from Microsoft, but in my experience the
complaint rate provided via SNDS/JMRP is almost useless: I speculate
that when your IP have a low reputation (or maybe when the IP is
red/yellow) for Microsoft, then they won't send you the FBL or maybe
they only send a percentage based on reputation.
In fact I guess Microsoft doesn't send all the complaints collected to
anyone: we always saw FBL/open rate much lower (half or less) than
other FBL enabled providers.
Also, I see our "worst IPs" are the ones for which we receive less FBL
from Microsoft: in fact we use FBL from other providers to identify
bad senders because microsoft seems to send us only FBL from good
senders (that's weird, and probably more complex than this, but this
was my "take away").

I also "guess" the whole thing slightly depends also on the network
you use and maybe some large IP class (or maybe ASN level) reputation:
what is your range? where are the IP "hosted" (routed)?
I say this because we had an IP range sending in "round robin" the
same emails of another IP range and one of the 2 turned red in July
and we had no way to understand why: we tried anything and we slowling
stopping using that range for microsoft (same emails from the other
range are happily delivered and the IPs are always green).

How do you allocate IPs? Are they shared-IPs or dedicated ones?

> We do not have a clue what this has caused.
> I've already contacted the deliverability support (multiple times), but more 
> than "do not qualify for mitigation at this time" or "At this point, I would 
> suggest that you review and comply with Outlook.com's technical standards." 
> as a reply i do not get. It is just ticket ping pong.

Same here: I bet they also tells you it's "based on the
recommendations of the SmartScreen® Filter" and "Because of the
proprietary nature of SmartScreen® and because SmartScreen® Filter
technology is always adapting and learning more"... "it is not
possible for us to offer specific advice". I never understood how much
they can really "debug" SmartScreen decisions: for sure they don't
share a single bit about them.

The only technical recommendation I can give is: make sure your emails
pass a "SenderID-PRA auth check" (change the SPF for the mime-from
domain or add a "Sender" header using the same domain you use in the
return-path so to fallback to "simple" SPF): everything failing this
check will go to Junk and bring you to the "yellowish" side of SNDS
and the more your IPs stay Yellow, the more your range is at risk of
this kind of "range block" (check "X-SID-Result" and "auth:" in the
"X-Microsoft-Antispam-Mailbox-Delivery" headers)

Please note I'm just speculating as no one from Microsoft ever
answered me anything useful to identify issues nor confirmed my
speculations (the only interesting things came from Micheal Wise,
here, but of course we can't expect him to check every single issue
that is not handled by Microsoft ticketing staff).

One more thing I "fear" causes issues with Microsoft is engagement
based sending behaviours: when you stop sending to inactive users then
your open rate will improve, but your abuse rate will raise too and
maybe "smartscreen" doesn't like this. I evaluated this thing because
we started collecting issues with Microsoft when we started
suggesting/educating/forcing customers to slow down sending to
inactive users (on the other side, Gmail liked this a lot).

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail Postmaster IP reputation shift on July 2nd

[Stefano Bagnara via mailop]

On Fri, 5 Jul 2019 at 10:17, Mathieu Bourdin via mailop
 wrote:
> We just saw that Gmail Postmaster’s Tools shows a very unusual amount of our 
> IP’s as « bad » in the graphs.
> Domain reputation seems unaffected, but basically we see around 50% of our 
> IPs for July 2nd and 75% for July 3 going from green to red.
> I saw no changes in sending habits from the various customers I checked (as 
> they all have dedicated IPs it’s fairly straightforward).

I can confirm the same thing from July the 2nd and we are a small italian ESP.
We (our customers) never had deliverability issues with Gmail.

Openrate (30%+) does not seem to be affected.

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Is Yahoo retiring inactive addresses?

[Stefano Bagnara]

On Tue, 19 Mar 2019 at 12:13, Syed Alam  wrote:
> Since 8th of March we determined an enormous global increase of below bounce 
> message from Yahoo MX:
> 554 delivery error: dd Sorry, your message to x...@yahoo.com cannot be 
> delivered. This mailbox is disabled (554.30). - mta4101.mail.bf1.yahoo.com

I confirm we see an increase from a <0.1% rates of this error message
to 1%+ starting from 8 march.
Since March 17th we also see an additional "step" and the rate
increased to 2-3%.

> We are assuming it is really a hard bounce and Yahoo is retiring inactive 
> addresses.

Sounds sensible. An official statement from OATH would be even better :-)

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Sophos Time of Click protection

[Stefano Bagnara]

On Thu, 14 Feb 2019 at 11:58, Ken O'Driscoll via mailop
 wrote:
> On Thu, 2019-02-14 at 10:09 +0100, Stefano Bagnara wrote:
> > So, before I propose to use local whitelisting I'd like to understand
> > the global blacklisting causes :-)
> > (If there is some malicious activity going on we better find it,
> > instead of working around it)
>
> I understand. The following, in case you don't already know about them, can
> be useful sites for checking on URL/IP reputation outside of traditional
> RBLs:
>
> https://talosintelligence.com/ (Cisco)
> https://reputationauthority.org/ (WatchGuard)
> https://exchange.xforce.ibmcloud.com/ (IBM)

Thank you, but the only issue is from Sophos. We send from the same
infrastructure since 10+ years and there are no issues on the above
websites (we have a reputable history for our IPs/domains, we are not
aware of any malware issues in years).
I'm pretty sure this is a false positive from Sophos (maybe related to
a new CNAME, so a new host it doesn't know and some heuristic on the
hostname), so I wanted to know if anyone have experience with the
specific "Time of click" filter from Sophos (we don't have general
issues on our url reputations, only this Sophos weirdness on a
specific url, as far as I have been reported).

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Sophos Time of Click protection

[Stefano Bagnara]

On Tue, 12 Feb 2019 at 12:55, Ken O'Driscoll via mailop
 wrote:
> From recollection, Sophos used to use McAfee's engine in some of their
> products so maybe try  https://trustedsource.org/ but my info might be out
> of date.

Interesting! I checked the URL there and it says:
- Status: Categorized URL
- Categorization: "- Internet Services"
- Reputation: Minimal Risk

Maybe it is not the same filter, or maybe the filter have been updated
in the mean time and the next email will simply work!

> Also, the recipient is empowered to whitelist you at any time, regardless
> of what Sophos product they are using.

The main issue is the number of "degrees of separation" between us and
the recipient :-)  (I have to write to my customer, that will have to
write to his customer and the third customer is the sender that can
talk to the recipient)

Furthermore, if I tell my customer "tell your customer recipient to
add a whitelist" he will reply with the following:
1) And what about the other recipients who are not aware of this? Will
they keep seeing the warning for our emails?
2) So if you ask the recipient to add a white list it means you (me)
are blacklisted

So, before I propose to use local whitelisting I'd like to understand
the global blacklisting causes :-)
(If there is some malicious activity going on we better find it,
instead of working around it)

Thank you, Ken!

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Trendmicro "BLOCK-SEND-ER"

[Stefano Bagnara]

On Tue, 20 Nov 2018 at 16:20, Laura Atkins  wrote:
> Are you able to deliver mail to any other trendmicro.eu hosted domain?
> If so, this isn’t a trendmicro issue, it’s an individual company deciding to 
> block specific senders.
> Asking each company to unbock / whitelist you is about your only choice.

We are not getting that error from every trendmicro.eu hosted domain,
but only a few of them (very few).
The first company (few weeks ago) replied that they didn't have
anything special configured to refuse our email and that they simply
used an "aggressive" level for filtering (I don't know what are the
configuration options for their users), so they added our IPs/domains
to their whitelist.
I'm waiting for a reply from the second domain postmaster@ address.

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Trendmicro "BLOCK-SEND-ER"

[Stefano Bagnara]

Is there anyone from Trendmicro or someone with suggestions about how
to deal with this error?
554 5.7.1 : Recipient address rejected: BLOCK-SEND-ER.
(in reply to the RCPT TO:)

The target email domain is hosted on in.hes.trendmicro.eu

I've looked up the sender IP (a shared IP: 213.171.189.7) in the
TrendMicro reputation service
(https://www.ers.trendmicro.com/reputations) and the result is
"Unlisted in the spam sender list", "Listed in: None".

The same recipient correctly receives the same content from another IP
(from Gmail).

I'm in touch with the domain postmaster, but this happened with
another domain and a different IP some weeks ago and they manually
whitelisted us, so this new error make me think there's something else
I should take care.

Stefano

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Libero.it delivery issues

[Stefano Bagnara]

On Wed, 17 Oct 2018 at 06:27, Benjamin BILLON  wrote:

> Hello,
>
>
>
> This isn't supposed to be temporary, it's been like this for months
> (although they're enforcing this gradually, I've heard of senders throttled
> 6 months ago, in my case it only started this summer). They're just not in
> the game anymore, they don't have enough resources. Users aren't receiving
> their emails, their market share might decrease in favor of Gmail.
>

We almost never saw a connection refused by Libero in the past months, but
yesterday.
Yesterday, instead, we recorded thousands of connection refused between 8AM
and 10AM (GMT+2): rest of the day and today everything is back to normal.

I have to say we only use 1 single connection per IP to Libero servers as
we found Libero enforcing this limit too often to try to use more
connections.

How do you say "they are not in the game"? we target mostly the italian
users and I don't see this drastic market share issue for Libero. In terms
of clicks, we saw a 2x increase from Gmail in a 24 month comparison, while
other providers (everyone else) are almost stable over the same period.
Clicks are a good "evidence" of the health of the inboxes. Libero+Virgilio
(ItaliaOnLine) inboxes still counts 18% of clicks for a "mostly italian"
user base.

Stefano
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Is SenderID deprecated? YES IT IS

[Stefano Bagnara]

On Fri, 5 Oct 2018 at 20:08, Ken O'Driscoll via mailop
 wrote:
> Hi Stefano,
>
> if you want to see who is querying what records then simply enable query
> logging on the authoritative servers for a sample domain and test away.

 spf2 (senderid) records and spf1 (spf) records are both TXT
records: a DNS clients simply lookup TXT records, they don't tell
which one they will read or they are looking for.

> Having seen the results of such an exercise by an ISP, I will save you the
> trouble by telling you that will not see requests for Sender ID (or other
> legacy protocols) from anyone.

I don't understand how this was "monitored": hope you can share more details.

> > And, that said, then don't tell that "SenderID" specification can be
> > ignored...
>
> Yes you can, Sender ID is completely depreciated.

I have doubts, it may be dead as "DNS record", but IMHO microsoft is
still using it, using the SenderID spec against the SPF record.

> RFC 4406 only ever reached experimental and is now about to be moved to
> historic.
>
> It is not supported in software anymore and is really not considered by
> anyone.

Outlook.com clearly log that in the header, so they still implement
it. Outlook.com have a great share of received email, so I don't
ignore it.

> There are no longer any Sender ID implementers. It is dead.

How can you tell this? Outlook.com clearly implements it: headers are
there. How do you define "implementers"?

> You are free to publish as many records for legacy protocols as you like,
> but it will not impact deliverability.

Well, I really have tested this in the past year, over few millions email.
Comparing email using the "Sender" header so that SenderID passes, to
the same emails NOT using the Sender header (so SenderID failed, but
SPF and DKIM passed anyway) I measured a slightly better open rate for
the ones using Sender (so I guess better inboxing). And this happened
to both O365 domains and to other domains that could have been handled
by some exchange but I have too few data to confirm. I didn't see
major differences in the Outlook.com deliverability, but I have to say
that deliverability on Outlook.com mainly depends on what the
recipients did with previous emails, so this kind of "A/B" tests
hardly works with it.

> > What I care is the sentence "Everything is SPF these days in both O365
> > and Outlook.com.  Some headers might mention PRA/PRD as the entity
> > among all the sender related headers that was selected to do the check
> > against, but this selection is done the SPF way." does not say "we
> > still implements SenderID but limited to reading SPF1 records":
>
> You're worrying about semantics too much. Microsoft KB articles and an MS
> rep on this very thread (quoted above) have indicated that Sender ID is not
> implemented by them. It's pretty clear.

Semantics? I did a lot of tests that gave me a result contrasting the
KB. I see headers in Outlook.com contrasting the KB (if you don't
implement a specification you can't add an header that pass or fail
according to that specification)..  They for sure implement senderid
as they add the header there... I don't know if the use SenderID for
spam scoring/reputation, but if they don't do that, then they have
other logic related to the "Sender" header in place.

> > Outlook.com headers clearly tell me that SenderID is still "computed"
> > using the Sender header and other SenderID rules... I'd like to know
> > if this is just some trash in the headers or if they actually use it
> > in any way.
>
> Those headers do not "clearly tell" anything other than that they were
> added by the receiving mailbox provider, likely for internal diagnostic
> purposes rather than as a message to you the receiver.

I don't care about messages for the receivers.. SPF/SenderID have not
been created to send messages to receivers... I measured that adding a
Sender to messages in order to let them "pass" a SenderID check
improved their deliverability..
If you prefer to think they add that header for no reason, it's up to
you... I can't say you are wrong, for the same reason you can't say
I'm wrong ;-)

> And, trying to understand how a mailbox provider's filters operate based on
> the discretionary header values they add to received emails is a futile
> process.

Sure, I did that by monitoring deliverability over a lot of
messages... Looking at headers is also another task I do.. How do you
do that?

> There's really nothing else to say about Sender ID - it's dead.

The code seems still alive in microsoft server (and we're not talking
about some foobar company). At the very least, they keep it alive just
to fill in some headers so to keep us bother about it.

I pr

Re: [mailop] Is SenderID deprecated? (Udeme Ukutt)

[Stefano Bagnara]

On Fri, 5 Oct 2018 at 18:55, John Levine  wrote:
> Mail systems can do whatever they want internally.  But I am pretty
> sure that even Hotmail/Outlook/Live/whatever will not ask your DNS for
> Sender-ID records any more.

How do you know that? Aren't they simple "TXT" records? How do you
know what a dns lookup will read once it asked for TXT records?

And, that said, then don't tell that "SenderID" specification can be ignored...
SenderID always abused SPF and if they now stopped reading spf2.0
records, then the spec (rfc4406) is still alive, and still abusing SPF
records (but using SenderID rules) defined in rfc4408.
If SenderID implementors still apply SenderID specification but
ignoring the spf2.0 records, I guess this is worse than keep
supporting the record (at least I could publish an "spf2 +all" record
if I didn't want my SPF record to be "misused" with the senderid
logics.

What I care is the sentence "Everything is SPF these days in both O365
and Outlook.com.  Some headers might mention PRA/PRD as the entity
among all the sender related headers that was selected to do the check
against, but this selection is done the SPF way." does not say "we
still implements SenderID but limited to reading SPF1 records":
Outlook.com headers clearly tell me that SenderID is still "computed"
using the Sender header and other SenderID rules... I'd like to know
if this is just some trash in the headers or if they actually use it
in any way.

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SmartScreen weirdness

[Stefano Bagnara]

On Fri, 31 Aug 2018 at 00:02, Michael Wise  wrote:
> /me coughs discretely ...
>
> As I don't have the right crescent wrench to what this issue, I have 
> forwarded your concerns to the people who ARE in a position to get a better 
> understanding of these issues.
> There's a lot of conflicting signals that SmartScreen takes into 
> consideration, and a lot of ... obscure-on-purpose policies that affect how 
> the folks who are typically the ones to mitigate these issues are allowed to 
> do ... and yes, a lot of boilerplate, sometimes that doesn't seem ... on 
> point.
>
> /sigh
>
> I will do what I can.

Hi Michael,

Did you get any answer/update? Or is this still under investigation?
Or trashed as "uninteresting"?

Since I wrote the post (almost 4 weeks ago) the IP 188.165.188.85 is
still the only red IP in our 100+ IP list and it always kept his "red"
status in the last weeks. No new trap hits, no new FBL and complaint
rate fixed to "< 0.1%".
Brothers IPs in the same pool like 188.165.188.87 have been always
green, as before.

Stefano

> Aloha,
> Michael.
> --
> Michael J Wise
> Microsoft Corporation| Spam Analysis
> "Your Spam Specimen Has Been Processed."
> Got the Junk Mail Reporting Tool ?
>

> > -Original Message-
> > From: mailop  On Behalf Of Stefano Bagnara
> > Sent: Thursday, 30 August, 2018 17:40
> > To: mailop 
> > Subject: [mailop] SmartScreen weirdness
> >
> > Hi all, or I should probably say Hi Michael, :-)
> >
> > I manage a pool of 5 IPs shared by the same group of senders (>100 small 
> > senders).
> > IPs are 188.165.188.85..188.165.188.89. (please no OVH-flames)
> >
> > They are low volume and they sends the same things (emails are 
> > roundrobin-ed between the IPs). They share the same reputation of public 
> > reputation providers (99 on senderscore, good on Talos). They haven't been 
> > blacklisted recently (AFAIK).
> >
> > One of those IPs is RED on SNDS (188.165.188.85) and in fact, emails sent 
> > by that IP to new email addresses ends up in the Junk folder. The other 4 
> > IPs are GREEN and have always been GREEN and an email sent to a new 
> > recipient is sent to inbox. I say "new recipients" because if I send an 
> > email to an "old recipient" that is already reading that email flow the 
> > email is inboxed by both. It's hard to "debug" this from the outside 
> > because I need reports from "new users" or I'd have to create new hotmail 
> > accounts.
> >
> > In the last 2 months I received only 1 FBL for that IP, and a total of
> > 12 FBL from the other 4 IPs (not daily, 3 in the whole 2 months). SNDS 
> > doesn't report a single spamtrap hit. The volume recorded by SNDS is 
> > between 500 and 1000 messages per day from each IP. Complaint Rate is "< 
> > 0.1%" Trap Hits is 0.
> >
> > I filled the Microsoft Form (SRX1437934126ID ). They told me it's because 
> > of "SmartScreen" and that they are unable to offer mitigation for that IP.
> > The conversation included the "usual" template-based (telling me to use 
> > JMRP/SNDS) answers: got 4 of them until they stopped answering me begging 
> > for "details" or "escalation".
> >
> > I'd like to identify the issue (if there is a bad sender I'd like to simply 
> > kick him), but I don't have data to use to do my "homework". I also can't 
> > get why 1 IP is "so bad" while the other 4 in the same pool are pretty 
> > good, while they simply send the same stuff.
> >
> > I saw in past Microsoft IP based reputation have a very long memory, so I 
> > guess it must have something to do with very old sending history from that 
> > IP (I can't be sure if something bad happened years ago.. I don't think so, 
> > but I can't exclude it).
> >
> > I also don't understand what could be the reason behind the answer "the IP 
> > cannot be mitigated": is it because it is not blocked and mitigation 
> > happens for blocks that are not depending from SmartScreen?
> > Or is it because they are actively seeing bad inbound flow from the IP and 
> > the reputation is "so bad" that they can't mitigate it?
> >
> > Michael, do you have an answer for this "scenario" or this specific case?
> > Others: did anyone else see similar issues? How did you fix them?
> >

--
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] SmartScreen weirdness

[Stefano Bagnara]

Hi all, or I should probably say Hi Michael, :-)

I manage a pool of 5 IPs shared by the same group of senders (>100
small senders).
IPs are 188.165.188.85..188.165.188.89. (please no OVH-flames)

They are low volume and they sends the same things (emails are
roundrobin-ed between the IPs). They share the same reputation of
public reputation providers (99 on senderscore, good on Talos). They
haven't been blacklisted recently (AFAIK).

One of those IPs is RED on SNDS (188.165.188.85) and in fact, emails
sent by that IP to new email addresses ends up in the Junk folder. The
other 4 IPs are GREEN and have always been GREEN and an email sent to
a new recipient is sent to inbox. I say "new recipients" because if I
send an email to an "old recipient" that is already reading that email
flow the email is inboxed by both. It's hard to "debug" this from the
outside because I need reports from "new users" or I'd have to create
new hotmail accounts.

In the last 2 months I received only 1 FBL for that IP, and a total of
12 FBL from the other 4 IPs (not daily, 3 in the whole 2 months). SNDS
doesn't report a single spamtrap hit. The volume recorded by SNDS is
between 500 and 1000 messages per day from each IP. Complaint Rate is
"< 0.1%" Trap Hits is 0.

I filled the Microsoft Form (SRX1437934126ID ). They told me it's
because of "SmartScreen" and that they are unable to offer mitigation
for that IP.
The conversation included the "usual" template-based (telling me to
use JMRP/SNDS) answers: got 4 of them until they stopped answering me
begging for "details" or "escalation".

I'd like to identify the issue (if there is a bad sender I'd like to
simply kick him), but I don't have data to use to do my "homework". I
also can't get why 1 IP is "so bad" while the other 4 in the same pool
are pretty good, while they simply send the same stuff.

I saw in past Microsoft IP based reputation have a very long memory,
so I guess it must have something to do with very old sending history
from that IP (I can't be sure if something bad happened years ago.. I
don't think so, but I can't exclude it).

I also don't understand what could be the reason behind the answer
"the IP cannot be mitigated": is it because it is not blocked and
mitigation happens for blocks that are not depending from SmartScreen?
Or is it because they are actively seeing bad inbound flow from the IP
and the reputation is "so bad" that they can't mitigate it?

Michael, do you have an answer for this "scenario" or this specific case?
Others: did anyone else see similar issues? How did you fix them?

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail - Anybody out there from Gmail, willing to assist with strange reputation issue

[Stefano Bagnara]

On Thu, 23 Aug 2018 at 21:14, Jan Schapmans  wrote:
>
> list is acquired by a webform where users request a valuation of their car
> customer doesn’t want to do double optin, we are pushing to only implement it 
> for gmail & googlemail addresses.
> (do you think gmail is also monitoring other domains? google apps?)

So, what does it happen when the user fill in the webform?
You simply put the email in the DB and use it later? Or what else?

But yes, doing "non confirmed" opt-in today is risky, and you just
discovered some of them: just report back to the customer and let him
decide if he still wants single opt-in even if this means "junk
folder".

And yes, GSuite domains all counts in the reputation for Google, so if
you have inboxing issues to Gmail you most likely can see them on
GSuite domains too. There are a lot of business domains there, today
and if you want to treat them differently from other you'll have to
start collecting the MX for each domain and add rules for MXes.

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Is the 3rd-party reporting DMARC record required?

[Stefano Bagnara]

On Thu, 16 Aug 2018 at 17:59, Andrew C Aitchison  wrote:
> [...]
> The difference is that by ignoring "external destination verifications"
> the personal data is going to someone who had no reason to expect it
> and has not indicated that they have procedures for handling it safely.
>
> If you do DMARC reporting right, there is scope for arguments that
> you are handling the data responsibly; if you mess up 3rd-party reports
> your defense falls apart.

I don't think a court would consider this in any way, but we'll see in future.

The publisher of the DMARC report is telling you what email address
should receive reports... the receiver is sending there the datas on
"request" of the domain owner (the DMARC rua/ruf records are a
"request" by someone that should have the right to make this request)
.. if they are not the right recipients then the domain owner is the
one that will have problems with GDPR, not the DMARC reporter.

Otherwise if you have a forwarder or a mailinglist where the
recipients are handled by your users and one day one of the recipients
of the forwarding/mailinglist change ownership you (system
administrator) would be liable according to GDPR: this is not the
case, hopefully. Or just a single user forwarding an email with PII
data to a third party user: you "the underlying forwarder" are not
reposponsible (according to GDPR) if they put the wrong address and
the receiver receive that email against his will... this is only a
spam issue (maybe ePrivacy will regulate this, but GDPR does not).

We may discuss if GDPR let you publish a DMARC record asking for
rua/ruf reports or not or if you have to ask for specific permissions
from your users before you can do that, but once you are allowed to
publish the record and receive reports I see no GDPR regulations
involving the "reporters" as they simply do what the
controller/other-processor asked them to do.

I keep thinking the "verification record" is only a spam prevention
tool and unrelated to GDPR. This doesn't mean it shouldn't be
implemented correctly, but simply that GDPR is already "broad" enough
even if we don't abuse of it.

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Is the 3rd-party reporting DMARC record required?

[Stefano Bagnara]

On Thu, 16 Aug 2018 at 15:58, John Levine  wrote:
>
> In article 
>  you 
> write:
> >On Wed, 15 Aug 2018 at 00:32, Steve Jones via mailop  
> >wrote:
> >> [...]
> >> It should never have happened period, and was probably actionable under
> >> the previous legal regime in the EU, had it been known. However now that
> >> GDPR is in force, I would think that should be considerable additional
> >> incentive for report senders to correct this situation ASAP.
> >
> >Most RUA/RUF emails are not "personal" at all, so they are not
> >regulated in any way by GDPR.
> >GDPR is about data protection where data is "personal data".
>
> Many of the failure reports I get are real mail that has been sent
> through a mailing list.  It has the real name and address of the
> person who wrote the message.  If that's not personal data, I don't
> know what is.

How is this related to "external destination verifications"?
How implementing that verification would stop the issue you're describing?

I thoung the topic was about flooding/spamming innocent email
addresses without their consent by adding their address in some DMARC
RUA/RUF attributes, without their consent (the author linked
https://tools.ietf.org/html/rfc7489#section-7.1 ).

I simply reported that if you use a record with "
rua=mailto:dm...@example.net; then "dm...@example.net" data is not
considered "personal" and is not regulated by the GDPR, so I don't see
how GDPR impact the use of the "verification record" in case of
external reporting addresses.

"ePrivacy" law, that currently is only a draft, may change something
about this, but we'll better talk about it when it will not be a draft
anymore.

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail change DMARC Policy?

[Stefano Bagnara]

On Thu, 2 Aug 2018 at 14:54, Bill Cole
 wrote:
> What I actually do not understand is why anyone (like BOTH of these
> senders) is bothering to DKIM-sign mail in ways that CANNOT align for
> DMARC and don't even match any domain in any header other than a
> signature. e.g.:

Providers are actively monitoring/building domain reputation based on
DKIM signatures, even if there is no alignment (alignment is a concept
that doesn't even exists in DKIM.. it is a DMARC stuff).
Some provider sends you FBL only if you DKIM sign emails (and they
don't care about alignment, because it is not a DKIM stuff).

So, one may care about DKIM even if they don't care about DMARC.
Alignment is a DMARC stuff. DMARC is newer than DKIM and DKIM didn't
require alignment for a reason.

If you want GPT or Yahoo FBLs for an email flow sent by SMTP servers
under your control but where you can't control the thousands of
different "From:" used, then you DKIM sign using your own domain and
happily get access to GPT and Yahoo FBLs: isn't this a good reason to
do that? (you are not in the position to refuse sending those emails,
you can only choose to add a signature or not).

In our case our main DKIM-signature for any email sent by our servers
always matches the return-path domain, the HELO and the FCrDNS. It
often doesn't match the MIME From, so it doesn't align.
When we can do it we add a second signature aligned to the From, but
we can't do that for every email.

Domain owner today can use DMARC to enforce alignment, but it is their option.
Receivers can ignore non-aligned DKIM signatures (no one force them to
read them).

If you ignore DMARC there is not so much difference in "transparency"
or "inscrutability" between a

Sender: "ME" 
From: "ME" 
DKIM: d=yourdomain

Compared to

From: "ME" 
Reply-to: "ME" 
DKIM: d=yourdomain


The first is not aligned, the second one is aligned.. when DMARC is
enforced people moves from the first to the second.. but there is not
so much difference in the way most users will read the 2 emails.
So I don't think there's a big "logical reason" they should be handled
so differently with regard to spamminess.
In both case you may want to assign a reputation to the sender IP and
to the signing domain and use them in your spam-scoring.

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] DKIM headers - which do you sign and why?

[Stefano Bagnara]

On Wed, 1 Aug 2018 at 20:56, Brandon Long  wrote:
> I pinged the bug I filed about not supporting the size limits on rua 
> addresses that I filed a year ago.
> [...]
> It looks like this affects about 1% of the reporting addresses we see, and 
> 0.01% of the mail.

Well, I guess some people that tested it, dropped it when they saw no
reports from Google and Yahoo, like me :-)
If only I knew there was a "known bug" I wouldn't have used that
feature from the start, but thank you anyway for acknowledging it now!

In my "sample" of 4 million domains, 78K publishes a DMARC record, 60K
use a third-party domain in their rua, 1060 use the "!sizelimit"
directive.
Half of them are from a single (French) ESP that suggests its users to
add that sizelimit when configuring their domain authentication.

Stefano

> Brandon
>
> On Wed, Jul 25, 2018 at 2:55 AM Stefano Bagnara  wrote:
>>
>> On Wed, 25 Jul 2018 at 11:22, Andreas Schamanek
>>  wrote:
>> > On Wed, 25 Jul 2018, at 10:40, Stefano Bagnara wrote:
>> > > To make a real example here is the record for the
>> > > "emailmarketingblog.it" domain:
>> > >
>> > > "v=DMARC1; p=none; sp=none; rua=mailto:dmarc##vox.it!10m;
>> > > ruf=mailto:dmarc##vox.it; rf=afrf; pct=100; ri=86400;"
>> > > (replace ## with @mail )
>> > >
>> > > And here the authorization record for the "cross-domain" report:
>> > >
>> > > # host -t txt emailmarketingblog.it._report._dmarc.mailvox.it
>> > > emailmarketingblog.it._report._dmarc.mailvox.it descriptive text 
>> > > "v=DMARC1"
>> >
>> > KISS! Start with
>> >
>> >v=DMARC1; p=none; sp=none; rua=mailto:dmarc##emailmarketingblog.it
>> >
>> > monitor for a while, and only then start adding the fancy bits.
>>
>> That's not KISS, as I would have to add a redirect in order to
>> automatically analyze reports then change the DMARC record every few
>> weeks to make some buggy provider happy.
>>
>> The DMARC spec is not so hard to be implemented.. I'd expect Google
>> and Yahoo to fix their reporting tools if they are not able to support
>> that syntax (but we still have to see if this is the issue or not, so
>> let's not jump to conclusions)..
>> And by comparing the Dmarcian report, every other provider but Yahoo
>> and Google, sends me the reports... I'd expect buggy or partial
>> implementations from "smaller" players, not from the bigger ones.
>>
>> Otherwise go evangelizing RFC authors about KISS! ;-)
>> SPF/DKIM/DMARC includes a lot of things that 99.9% of users will never
>> use, but still we (implementors) have to implement/support (e.g: less
>> than 0.1% of domains with an SPF record use SPF macros or exists: or
>> exp=, and those counts a lot of, often buggy, code in an spf
>> implementation).
>>
>> --
>> Stefano Bagnara
>> Apache James/jDKIM/jSPF
>> VOXmail/Mosaico.io/VoidLabs
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop



-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Gmail change DMARC Policy?

[Stefano Bagnara]

On Thu, 2 Aug 2018 at 00:45, Laura Atkins  wrote:
> [...]
> I’ve reached the point with Gmail that the filters are reasonably predictable 
> and can be managed. Even if it doesn’t make sense specifically, I’m pretty 
> sure the filters are acting “correctly” and that any deviation from what we 
> expect in delivery is a problem for the sender. It’s a black box but it’s a 
> consistent black box.
> Microsoft is now the industry black box that everyone is struggling with. 
> Those filters don’t seem to be acting consistently at the moment, so it’s 
> really tough to figure out what the problem is.

This is my "comparison" between the 2 :-)

1) Gmail: if the ESP signs every email with its own domain then its
own reputation is the "key".. if this is good then even spammers
sending from that ESP will get to inbox, if it is bad, even good
senders will go to spam (mostly).
2) Microsoft: IP reputation have a good weight, but when recipients
engaged with a previous email from a given sender they will keep
receiving that sender's emails in inbox. The "per recipient" filter
have much higher priority than the "reputation" filter.

1) In Gmail a good open rate will help a lot.
2) In Hotmail a low abuse report will help a lot. A good open rate may
kill you, if you get it by dropping inactive subscribers, because this
action will increase your "abuse ratio" (as inactive users don't
report abuse).

1) Gmail will react much faster to reputation changes (few days/weeks
may change a lot).
2) Hotmail is an elephant and bad reputation will be remembered for
months (or even years).

1) Gmail Postmaster Tools reports bad FBL "tokens" only over a given
amount: it is too high if you are monitoring small senders.
2) Hotmail FBL gives you single abuse reports but looks like they
report only part of them.

1) GPT "color" seems related to the inboxing.
2) SNDS "color" sounds completely unrelated to inboxing.

1) Hotmail is hard when you have a lot of "new" recipients
2) Gmail is hard when you have a lot of "old" recipients (with low
engagement due to obsolescence).

The strategy that fixes Gmail will break Microsoft and viceversa... so
you would need 2 different strategies.

IMHO,
Stefano

>
> laura
>
>
> On Aug 1, 2018, at 10:22 AM, Brandon Long via mailop  
> wrote:
>
> I'd say it's unlikely that we have some list, usually we try to solve these 
> things based on the automatic stats we're already keeping, ie volume and 
> reputation and probably any number of other features of the message.
>
> So, it could be caused by changes in the reputation of your esp.  It could 
> also be due to more attacks against gmail.com leading to stricter handling.
>
> The team still has a goal for going to quarantine and reject for gmail.com in 
> the long term, so tightening rules about when we consider these forgeries as 
> forgeries is in line with that.  Not harming these types of small businesses 
> using esps is our largest blocker.
>
> Which is another way of saying that just because we're at p=none doesn't mean 
> forgery is a good idea, and sometimes we'll mark it as such.
>
> Brandon
>
> On Wed, Aug 1, 2018, 9:54 AM Laura Atkins  wrote:
>>
>> I’m not actually seeing a problem here or understanding what your issue is.
>>
>> In terms of the forgery message. I expect that Gmail is special casing some 
>> ESPs (like mailchimp, and I expect there are others). So they’re allowing 
>> customers of those ESPs to use @gmail.com addresses in the From: line and 
>> are not treating that as a forgery. It makes sense, as Mailchimp (like other 
>> ESPs), actually confirms address ownership before allowing it to be used as 
>> a From: address. Because the ESPs act responsibly, Gmail doesn’t need to 
>> warn that the mail might be a forgery. It’s not, the ESP has assured that.
>>
>> If you’re sending from a different place, one with unknown policies, then 
>> Gmail doesn’t know anything about that, so it offers the warning.
>>
>> All in all, quite a sensible implementation from Gmail.
>>
>> What’s the problem you’re trying to solve?
>>
>> laura
>>
>>
>> On Aug 1, 2018, at 8:52 AM, Emanuel Gonzalez  
>> wrote:
>>
>> Hello, thanks for the help and reply.
>>
>> The problem not solved.
>>
>> any ideas?
>>
>> Regards.
>> 
>> De: Stefano Bagnara 
>> Enviado: miércoles, 1 de agosto de 2018 12:18:41
>> Para: mailop
>> Cc: emanuel_gonza...@live.com.ar
>> Asunto: Re: [mailop] Gmail change DMARC Policy?
>>
>> On Wed, 1 Aug 2018 at 15:26, Emanuel Gonzalez
>>  wrote:
>> > I have a problem w

[mailop] Lost DMARC reports reason (Was: DKIM headers - which do you sign and why?)

[Stefano Bagnara]

On Thu, 26 Jul 2018 at 11:36, Stefano Bagnara  wrote:
> On Wed, 25 Jul 2018 at 22:28, John R Levine  wrote:
> > [... about "v=DMARC1" vs "v=DMARC1\;" ]
> > When you put in the missing semicolon, what happened?

Update: DNS propagated and I started receiving reports from Google and Yahoo BUT
- ONLY for the domains where I removed the  maximum-size specification
(!10m) from the email URI.
- NOT for the domains where the maximum-size specification is still
there (even if I changed the authorization record from "v=DMARC1" to
"v=DMARC1\;").

So, the fix (for me) is to avoid using the maximum-size specification
(use mailto:em...@example.com instead of mailto:em...@example.com!10m)
while altering "v=DMARC1" to "v=DMARC1\;" in the authorization record
didn't change anything.

Thanks to everyone involved in this thread! What we learned:
1) Google and Yahoo do not send DMARC reports when the rua/ruf
addresses includes the "maximum-size specification".
2) RFC is unclear about the minimal authorization record being
"v=DMARC1" or "v=DMARC1\;"
3) Most deployers used "v=DMARC1" (with no ";") in their existing
authorization records and, while it's not clear if this is "valid", it
seems to work fine anyway.

Stefano

-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] DKIM headers - which do you sign and why?

[Stefano Bagnara]

On Tue, 24 Jul 2018 at 09:19, Ken O'Driscoll via mailop
 wrote:
> On Tue, 2018-07-24 at 00:30 +0200, Stefano Bagnara wrote:
> > And still I'm honestly looking for stats about how many domains are
> > really currently sending DMARC reports to senders (I get reports for
> > much less than 1% of my recipients: is it what you all get or is there
> > something wrong in my setup/target?).
>
> https://us.dmarcian.com/dmarc-data-providers/

Great!

It's clear that I'm NOT receiving Yahoo reports, I don't know why...
Are there special requirements to receive them?

About google.com I see very low volumes in your report, so there must
be something "special" there, too... I can't believe your users send
to Google 10% of Yahoo and only 200% of Emailsrvr.com. May it be they
only report for google.com and not gmail.com? (then the volume is
high, but maybe this is about your special target)

Starting from the 3rd position I see the same domains reporting to me
(much less than 1% of total volume).

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] DKIM headers - which do you sign and why?

[Stefano Bagnara]

On Mon, 23 Jul 2018 at 23:50, John Levine  wrote:
> In article 
>  you 
> write:
> >On Mon, 23 Jul 2018 at 20:16, Steve Atkins  wrote:
> >> > On Jul 21, 2018, at 1:28 AM, Stefano Bagnara  wrote:
> >> > [...]
> >> > Otherwise we keep weakening DMARC to a point where it is not useful 
> >> > anymore.
> >>
> >> For many senders it's not useful; it's actively harmful. They're deploying 
> >> it because they've been
> >ordered to, or because they've received bad advice, or because they're 
> >copying others who've made poor
> >decisions.
> >
> >The "v=spf1 +all" SPF record is another, even easier, way to work around it.
>
> It doesn't work, of course, since mailing lists invariably use their
> own bounce address, not the one in the original author's domain.

Right. Sorry.

> >RFC6376 5.4. Determine the Header Fields to Sign:
> >"signing fields present in the message such as Date, Subject,
> >Reply-To, Sender, and all MIME header fields are highly advised."
>
> We wrote that a long time before anyone had imagined the mess that is DMARC.

Well, if it is not valid anymore then we need an update... "You" made
3 revisions between 2007 and 2011 and then stopped updating it when it
really started being used? ;-)
There's not even an "errata" for that.
Implementors (when they read the RFC) deserve to know what's the
*current* best practices suggested by the spec RFC.

> >May be another plan using multiple signatures.
> >
> >You can sign it twice, once with the "suggested" setup and once with
> >your "minimal" setup (a different selector and very fast-rotating
> >selector/keys). This way receivers that only wants to accept DKIM as
> >valid when enough headers and enough of the body is signed can still
> >accept one of your DKIM signatures.
>
> Sure, if you think that's useful.

I see your messages to this mailing list are failing DMARC and here
are their signatures:
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com;
h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding;
s=c4b4.5b538d77.k1807; ...
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com;
h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding;
s=c4b4.5b538d77.k1807; ...

I'm not sure I understand why (the rationale about it) you decide to
sign that headers and fail DMARC here, while you suggest the "asker"
to stop signing reply-to

And still I'm honestly looking for stats about how many domains are
really currently sending DMARC reports to senders (I get reports for
much less than 1% of my recipients: is it what you all get or is there
something wrong in my setup/target?).

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] DKIM headers - which do you sign and why?

[Stefano Bagnara]

On Mon, 23 Jul 2018 at 20:16, Steve Atkins  wrote:
> > On Jul 21, 2018, at 1:28 AM, Stefano Bagnara  wrote:
> > [...]
> > Otherwise we keep weakening DMARC to a point where it is not useful anymore.
>
> For many senders it's not useful; it's actively harmful. They're deploying it 
> because they've been ordered to, or because they've received bad advice, or 
> because they're copying others who've made poor decisions.

The "v=spf1 +all" SPF record is another, even easier, way to work around it.
Your messages will "DMARC survive" also every body changes applied by
any forwarders adding something to the top of the message or "fixing"
your message the way they know.

> Weakening it's guarantees *for those senders* mitigates that damage.
>
> It also *strengthens* DMARC for other senders, those using it legitimately, 
> as it reduces the number of recipient mailbox providers who stop enforcing 
> DMARC because it breaks delivery of legitimate email.

RFC6376 5.4. Determine the Header Fields to Sign:
"signing fields present in the message such as Date, Subject,
Reply-To, Sender, and all MIME header fields are highly advised."

RFC6376 6.1.1. Validate the Signature Header Field
"Verifiers MAY ignore the DKIM-Signature header field and return
PERMFAIL (unacceptable signature header) for any other reason, for
example, if the signature does not sign header fields that the
Verifier views to be essential.  As a case in point, if MIME header
fields are not signed, certain attacks may be possible that the
Verifier would prefer to avoid."

So, weakening it may produce a failure to some receivers even if the
message was not altered by anyone. Otherwise you could approach DKIM
"minimal" by only signing "From" header  and using "l=0" to avoid
signing the body (this is the minimal following the MUST, but it is
clearly discouraged by the RFC). Anyone with one of your signed emails
will be able to sign any message with your From header (very similar
to the SPF "workaround" above).

Today I don't think there are many "strict checkers" on the DKIM
verification side, but I think we'll see them being more strict as
soon as weak DKIM "patterns" will start taking traction. And how can
we be sure they are not doing that already? I guess that "paranoid"
receivers that apply strict rules are the same that will never send
you DMARC reports, too.

I couldn't argue to a receiver that will drop a message from a "v=spf1
+all" domain or a message that dkim signed only the "From" header and
0 body bytes.

I'm just playing Devil's Advocate.

May be another plan using multiple signatures.

You can sign it twice, once with the "suggested" setup and once with
your "minimal" setup (a different selector and very fast-rotating
selector/keys). This way receivers that only wants to accept DKIM as
valid when enough headers and enough of the body is signed can still
accept one of your DKIM signatures.

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] DKIM headers - which do you sign and why?

[Stefano Bagnara]

Here's mine:

h=from:to:subject:mime-version:sender:list-unsubscribe:content-type:content-transfer-encoding:feedback-id;

I saw some recommendation not to sign "To" but I don't think it is a
good practice (for the generic use case). If you don't sign the To
then anyone can "replay" your message to another recipient and make it
seem legit (pass DKIM).

Stefano

On Fri, 20 Jul 2018 at 07:21, Autumn Tyr-Salvia  wrote:
>
> Hello Email Folks,
>
> I work at Agari, where I guide large organizations through the process of 
> getting their email to pass DMARC. I have lately had some customers with 
> greater-than-usual issues relating to aligned authenticated messages that get 
> forwarded, where the forwarding system is changing headers to the point that 
> they break DKIM, and thus the messages fail and get rejected. The messages 
> they're having trouble with are being sent from servers under their own 
> control (and not third party vendors), and I have a sneaking suspicion that 
> the issue is related to the specific headers they have chosen to sign.
>
> I know signing the From: field is required by spec, but I think everything 
> else is technically optional. For those of you who have been in the position 
> of choosing which headers to sign and which not to, would you be open to 
> sharing your reasoning with me? Any words of wisdom around headers they 
> really should or should not sign?
>
> Insight much appreciated!
>
>
> Thanks,
>
> Autumn Tyr-Salvia
> tyrsalvia@gmail
> atyrsalvia@agari
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop



-- 
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Recent "banned sending IP" errors when sending to Microsoft

[Stefano Bagnara]

I saw this the first time on 15th may 2018. I unlisted an IP even today.

The unlisting is very fast and, at this time, IPs unlisted have not
been relisted.

In my case it happened with IPs from 3 different ranges. One of the
ranges had most of the IPs involved in the weeks, while the other 2
ranges only had few occourences.

Stefano

On Mon, 25 Jun 2018 at 18:33, Josh Campbell  wrote:
>
> Has anyone else noticed these errors? We hadn't really seen them previously. 
> They look like this:
>
> smtp;550 5.7.606 Access denied, banned sending IP [xxx.xxx.xxx.xxx]. To 
> request removal from this list please visit https://sender.office.com/ and 
> follow the directions. For more information please go to 
> http://go.microsoft.com/fwlink/?LinkID=526655 (AS16012609) 
> [AM5EUR03FT031.eop-EUR03.prod.protection.outlook.com]
>
> We've only started seeing them in the past month and only a small amount of 
> IPs have been affected at any one time.
>
> The interesting thing is all of these IPs are in the same IP range (out of 
> the three major ranges we have).
>
> I'm wondering if this is a new phenomenon for anyone else and why it only 
> appears to affect one of my IP ranges. (Also, if anyone from Microsoft cares 
> to get in touch, I'd love to hear from you.)
>
> Josh Campbell, Deliverability Engineer
> MailChimp
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop



--
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] News about the travails with my famous Y! trap account

[Stefano Bagnara]

On Wed, 20 Jun 2018 at 09:20, Philip Paeps  wrote:
> A disturbing number of "ordinary people" (who don't live in SMTP land)
> also believe that + is an "invalid character" in email addresses.

I have found a LOT of inboxes unable to redirect email to an address
that uses a "+" while being happy to redirect to a "-" address.

I used to collect email from various inboxes via "redirect" and I
wanted to redirect to a +tagged target inbox and failed to do that for
multiple inboxes, while they happily accepted a -tagged target.

IIRC at least the CriticalPath(OpenWave/Memova) "customers" have this
issue (in Italy we have major providers using their software): I don't
know if there is a "reason" for this, or simply a bug. You can write
an email to a "+" recipient, but you can't have a redirect rule to a
"+" recipient.

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Hotmail/msn/lutlook performing unsolicited updates to users' safe- and blocked-sender lists?

[Stefano Bagnara]

On Wed, 13 Jun 2018 at 20:50, Michael Rathbun  wrote:
>
> On Wed, 13 Jun 2018 10:13:35 -0600, Paul Kincaid-Smith 
> wrote:
>
> >if Microsoft's filters were aggressively moving heaps of *wanted* email out 
> >of
> >the inbox, I'd expect Outlook's read rates to be lower, but my metrics show
> >that read rates at Outlook are often in line with read rates at Gmail and
> >Yahoo!
>
> ...
>
> >(I'm probably measuring read rates differently than you. I use IMAP's
> >"message read" flag, not an open tracking pixel or click-tracking link.)
>
> I confess that I am not at all sure what you are doing, as we would normally
> not have IMAP access to a recipient's mailbox.
>
> Based on the usual crude tracking pixel and click-tracking links, we often see
> open rates at hotmail/msn/etc at under half those seen elsewhere.
>
> Thinking about performance objectives (having been a spam analyst for the
> Office 365 platform for a couple of years, ending just when the consolidation
> with the freemail service began), reflecting upon the fact that non-spam email
> can be several orders of magnitude more expensive to process and place in the
> inbox than spam, my thought is that
>
> 1.  It can be extremely economical to consult the recipient's local rules
> before even beginning to filter an incoming message; if it's subject to the
> local safe-sender list, mark it as safe and terminate all filtering.  At least
> a 10,000:1 resource saving.  If it would be nabbed by the recipient's
> blocked-sender list, mark it as spam and likewise send it on its way.
>
> 2.  Given the great desirability of completely eliminating the filter process,
> devise as many ways as possible to populate each recipient's safe and banned
> lists, regardless whether they would like you to do that.
>
> mdr
> --
>"There will be more spam."
>   -- Paul Vixie
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Misleading clicks - thoughts

[Stefano Bagnara]

On Tue, 12 Jun 2018 at 10:25, Andy Onofrei via mailop  wrote:
> [...]
> I wanted to ask you if someone is experiencing misleading clicks ( caused by 
> spam filters or something similar and not by bot farms ).

Hi,

Here are some of the IPs doing more "non-humans" clics in my list:
199.19.249.196, 195.45.128.131, 50.19.154.226, 94.237.41.127,
88.198.94.196, 52.44.93.197, 72.30.14.126.
(216.244.66.199 and 216.244.66.246 seem to have stopped in march).

I didn't investigate on them.,.. but maybe you want to check your data.

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Should mail servers publish IPv6 MX records? Could this harm your spam filtering?

[Stefano Bagnara]

On Fri, 8 Jun 2018 at 18:14, Stefano Bagnara  wrote:
> On Fri, 8 Jun 2018 at 17:53, Michael Peddemors  wrote:
> > [...]
> > And while using that as feedback might seem the logical conclusion, in
> > the real world we still see more feedback reports from legitimate email
> > the customer should have wanted, vs emails tagged as spam that are spam.
>
> Well, this is very surprising to me. Anyone else record similar scenario?

Michael, I just noticed that I read your sentence in a wrong way. I read "more
no-spam reports than spam reports" while I should have read "most of
the spam reports received are submitted by mistake".
So my previous reply was written after this misunderstanding.

Now, if most spam reports are submitted by mistake by people that
doesn't really want to complain/stop received emails from that sender
then this make it even more important to be able to collect false
positives (or are you telling that user-originated-feedback is not
trustable enough that you can't use it for "false positives
reports"?).

On Fri, 8 Jun 2018 at 17:53, Michael Peddemors  wrote:
> IMHO, and the way most of our platforms are designed to work.. Empower
> the users when you can.. but block the worst of the worst..
>
> * Block at SMTP via RBL's that have very low false positive rates

How can you tell an RBL have "very low false positive rates" if most
of the users of that RBL use it at SMTP time (or if the "not-spam"
reports don't flow to the RBL operator)? This is a dog biting its
tail...

I read "Very low false positive rates" as "Very low
collected-false-positive rates" where we miss a
"collected-false-positive against false-positives rate".

In my small system I don't have a "false positive report", so If I
silently drop 5% of the traffic randomly at the smtp level I hardly
get any false positive report... this doesn't make the "randomly
dropping 5% of the traffic" a good/trustable block. Most people don't
know someone is trying to write them until they see the email and you
get a false positive only when the sender phone-call the recipient to
ask why he didn't reply (their next attempt only have 5% of chance to
get blocked again, so 0,25% to block 2 sends, and they won't care to
call me to complain).

Even if you have a good "rate" you could have a bad statistical
distribution (see my B2C vs B2B example at the end of this reply).

I don't want to delegitimize those RBL, but the "false positive loop"
is one of the key aspects of an automated system and its importance
increases as the "spam report loop" quality decrease. IMHO today there
are major holes in the false positive loop and this didn't improve at
all through the years.

How can the quality of the spam report loop be low?
1) you get it from the final user and, just like you told us, most of
them don't use this feature correctly.
2) you automate it with no "volume comparison", so you only evaluate
reports and not "everything else"
3) you works with hashes/fingerprints instead of full messages (it's
harder to manually review listing/delisting from something you can't
really "read").

Why is this "in topic"?
1) IPv6 enable more "scattering" and IP based RBL are less effective
for low-volume senders (the lower the volume, the lower the
statistical significance, the higher the error)
2) If you move to a fingerprint (content) based blacklist and you do
that working mainly with hashes (like CloudMark Authority) you don't
know anymore what you are really going to block, until you start
blocking it.

I'm sure CloudMark (CA: CloudMark Authority) have major "false
positive loops" but I'm aware of multimillion-inboxes-providers using
it only to block emails and to send "spam reports" (no false positive
report loops).

To name names, in Italy "Libero.it" (ItaliaOnLine) the largest italian
inbox provider (10-15 million inboxes) uses CloudMark and AFAIK send
them spam reports, non-spam reports and (I'm less confident about
this, but I think they do) "volume data" about fingerprints and they
never reject at SMTP time because og this.

On the other side "Aruba" the largest B2B italian inbox provider (7
millions inboxes) uses CloudMark and AFAIK send them spam reports, DO
NOT send "non-spam reports" and on recipient option they may reject
emails (not at SMTP time, but via bounce... but the recipient doesn't
get the email).

So, if you do B2C or mixed B2B/B2C to Italy Cloudmark works mostly
well (they easily block fingerprints, but then they get false positive
reports and unblock), but if you only do B2B traffic you'll often hit
some Cloudmark block with many false positives that are not collected
by Cloudmark that can't never decide to unlist on its own.

PS: I talk about CloudMark bec

Re: [mailop] Should mail servers publish IPv6 MX records? Could this harm your spam filtering?

[Stefano Bagnara]

On Fri, 8 Jun 2018 at 19:31, Michael Peddemors  wrote:
> On 18-06-08 09:14 AM, Stefano Bagnara wrote:
> > [...]
> > In fact I still have to understand how spam reports and false positive
> > reports are collected in the whole plesk world (I guess you know what
> > I'm talking about): [...]
>
> Well, like any system, I think that you are probably looking at this too
> simply, it could be that the system administrator has chosen to reject
> instead of flag.. It depends on the system implementation.  This isn't
> related to any specific RBL, but how it is used.
>
> Some use it to 'block', some use it to tag, and it doesn't matter which
> RBL it is, SpamHaus, SpamRats, UCE-Protect, Invalument, Barracuda.. (or
> a subset of their offerings) or a more specific purpose list..

I agree, but when a lot of users for an RBL use it to reject at the
smtp level then you loose your false-positive feedbacks.
If there a big sample of users that use the list but are not able to
report false positives, then you can't say anymore that the list have
"low false positive".

In order to try to go back in topic, I think this "false positive
loop" that is often missing for smaller users that simply stack up a
number of DNSBLs and reject for every match, is an issue and an issue
that need more attention and priority than the ipv6 stuff.
IPv6 will increase the fragmentation and more fragmentation will mean
more servers with low volumes and more servers with low volumes means
much more chance of false positive listings... and if you don't have
an almost 100% coverage for false positive collections this is going
to fall apart.

Unfortunately I don't have a recipe or a proposal about how we could
make it possible for recipients (they are the first source of the
truth wrt spam) to report false positives for email they didn't
receive at all because of the RBL used at SMTP rejection.
Also there are a lot of final users using emails systems with
mark-as-spam and mark-as-no-spam buttons that in the end do not
generate spam reports or false positive reports to the systems
resposible for that classification.

> [...]
> But it does depend on the technology being used by that operator.  Some
> will only be able to do it at one level or another, but it still creates
> less problems than if they didn't have it in place.

I don't fully agree.
1) In the plesk world (as I took that as an example) there are
defaults and  the defaults are not an "operator" stuff (AFAIK the
DNSBL enabled by default don't get any false positive reports from
plesk users)
2) When we talk about RBL we are not only talking about the technology
itself, but also in how they are (and can be realistically) operated..
The whole IPv6 RBL discussion is about that, IMHO... the technology
itself could work... but in order to make it work you would have
higher costs and a lot more resources to be invested in the way you
"operate" it, in order to get similar efficiency. So we can't prescind
from how RBLs are "usually" operated when we try to understand their
status and their potentials.

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Should mail servers publish IPv6 MX records? Could this harm your spam filtering?

[Stefano Bagnara]

On Fri, 8 Jun 2018 at 17:53, Michael Peddemors  wrote:
> [...]
> And while using that as feedback might seem the logical conclusion, in
> the real world we still see more feedback reports from legitimate email
> the customer should have wanted, vs emails tagged as spam that are spam.

Well, this is very surprising to me. Anyone else record similar scenario?

I know much more users that use the "mark as spam" on their inboxes
than users that dig in their junk folder to mark something as "non
spam".
I'd love to get some stats about "mark as spam" vs "mark as non spam"
from Google or Microsoft, just to get some real data about this!

And I know a lot of systems where there's no spam folder in "inbound"
but there's a "mark as spam" so that you can only make reports for
spam but you can't really make reports for non spam.

In fact I still have to understand how spam reports and false positive
reports are collected in the whole plesk world (I guess you know what
I'm talking about): I've had multiple recipients using plesk that were
willing to report false positives for the MIPSPACE-POOR list (or other
lists used there by default) but I've not been able to explain them
how to report the false positive and had to explain them how to remove
the MIPSPACE-POOR lookup. I really tried hard to find a better way
than explaining them how to disable that list, but failed.

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Should mail servers publish IPv6 MX records? Could this harm your spam filtering?

[Stefano Bagnara]

On Fri, 8 Jun 2018 at 16:47, Jim Popovitch via mailop  wrote:
> On Fri, 2018-06-08 at 10:27 -0400, Rob McEwen wrote:
> > there has to be some justified level of "collateral damage" these
> > days, due to the very high frequency of hijacked accounts, hijacked
> > websites, and spamming ESP customers (from ESP that are overall
> > good).
>
> Rather than dumping a piece of technology (ipv6), dump the ESPs that
> enable cheap sending. (Win! Win!).  If those ESP customers had to build
> out their own infrastructure then they would take better care of it...
> regardless of ipv4, ipv6, ipv8, etc.

If you really think that rejecting email from senders that want to
optimize their costs is a good strategy
Well, IPv6 is simply a way to make email sending cheaper. So not
supporting Ipv6 is an effective way to dump cheap sending.

I guess anyone with a good corpus can easily check that "inexpensive
ESP" are not more spammy than "fortune 500 ESP".

Someone proposed to simply add some cost to every SMTP transaction as
a way to stop the spam, some blacklist offer paid unlisting services,
too... but spammers sometimes have more money to send email than the
average user IMHO.

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Should mail servers publish IPv6 MX records? Could this harm your spam filtering?

[Stefano Bagnara]

On Fri, 8 Jun 2018 at 13:57, David Hofstee  wrote:
> Hi Stefano,
>
> The only problem I see with Cloudmark is that they are not just a reputation 
> provider, but a spamfilter provider with access to all the data. Which has 
> been acquired by Proofpoint.

Well it is a mix of reputation and filter.. the filtering is "ON/OFF"
and not reputation/score based. If one fingerprint is in the blocklist
the email is spam, otherwise is ham.
The "reputation" is involved in the way they take into consideration
the reporters or they decide to block or unblock a give fingerprint.
So it is not so different from an IP RBL.

What do you mean with "spamfilter provider with access to all the data."?
They don't see the whole email flow.. they mostly get fingerprint
lists for email being marked as spam or "non-spam" and an installable
peace of software (that you can add to your mailserver) do the
fingerprint extraction and is able to check if any fingerprint is
currently blocked, and then you can do whatever you want with this
information.

An email will result in 5, 10, 30 fingerprints depending on the number
of "intesting" things Cloudmark identify.

> I'm asking myself the question if the fingerprints they collect are GDPR 
> proof (although Jaren may comment on that).

We'll probably know this in a few years , as GDPR will start getting
used for real...
In the mean time they mostly deal with cryptographic irreversible
hashes of the email "fingerprints". GDPR call this
"pseudo-anonymization" because you if know the original personal data
you can find the fingerprint for it.

For example whenever an email contains a link or plaintext sequence
that sounds like an url and the domain is "gravatar.com" they will ad
a "AxTCswu-:8" fingerprint for that domain. This "AxTCswu-:8"
is the one that is blocked if they want to start blocking every email
referencing gravatar and the "block packages" their users download via
DNS micro-updates will simply contain this fingerprint as the
filtering can be done "offline" once you have the latest updates.
There are specific domains where the hash will be computed for every
subdomain and there are specific domains where another hash will be
computed depending on the path, e.g:
gallery.mailchimp.com, googleusercontent.com, www.youtube.com,
www.dropbox.com, goo.gl, tinypic.com and many other will generate a
"something:20" fingerprint that will be specific to a part of the
path. For url shortner is the full url, for others like
gallery.mailchimp it will include the "user specific" part of the url
so that they can identify a single mailchimp sender with a specific
fingerprint.
This "special" domain list is part of the "data", not of the
code/algorythm... When you receive the micro-updates with the
blacklisted fingerprints you may also receive updates about the
patterns that will generate the :20 fingerprints.

This is just a basic case of the most common patterns from CloudMark
Authority, but there is a lot more and their system is really
interesting: it is the most advanced of its kind. I think it is much
better than using a bunch of IP/URI BL at the SMTP level, but it is
far from perfect. E.g: given they don't have "volume" informations
they very easily block "new" fingerprints because of a couple of "mark
as spam" actions even if there were 2 "mark as spam" for 1 million
email delivered... then, you'll start being junked and they easily
will get "non-spam" reports and remove the fingerprint from the
block... I see a lot of new senders blocked at least once in their
first send and then unblocked after a couple of "junked" emails. Of
course this only works if you send blocked email to spam and you get
the "not-spam" reports.

IMHO this is GDPR compliant, not so different from IP RBL: they deal
with clear-text IP addresses and IP addresses are not even
pseudo-anonymized.
That said GPDR in the end doesn't make much differences between
personal data and pseudo-anonymized personal data... they both require
the same "legal" treatment, but if you use pseudo-anonymization you
can say you care more about the privacy leaks issues.

Stefano

>
> Yours,
>
>
> David
>
> On 8 June 2018 at 12:35, Stefano Bagnara  wrote:
>>
>> On Fri, 8 Jun 2018 at 11:53, David Hofstee  
>> wrote:
>> > [...]
>> > I also think that there is space for a reputation provider which can:
>> > - Identify more than just IP addresses and domains from an email.
>>
>> This is what CloudMark Authority does about this, but you enable a new
>> set of issues that have been just fixed in the IP/domain world thanks
>> to DMARC (I wrote an answer to the SDLU sister-thread).
>> IIRC 

Re: [mailop] Should mail servers publish IPv6 MX records? Could this harm your spam filtering?

[Stefano Bagnara]

On Fri, 8 Jun 2018 at 11:53, David Hofstee  wrote:
> [...]
> I also think that there is space for a reputation provider which can:
> - Identify more than just IP addresses and domains from an email.

This is what CloudMark Authority does about this, but you enable a new
set of issues that have been just fixed in the IP/domain world thanks
to DMARC (I wrote an answer to the SDLU sister-thread).
IIRC Vipul's Razor used the same fingerprinting concepts and ended up
using a DNSBL of "fingerprints". Vipul founded Cloudmark and I don't
know what is the current status of the Razor project.

> - Is able to process feedback from domain owners and recipients in an 
> automated, quick, effective and anonymous enough way (with the GDPR et al). 
> Feedback is key.

I strongly agree with "Feedback is key" both for "spam reports" and
"non-spam reports" (and considering that "non-spam" only flows if you
didn't block at the SMTP level).
Unfortunately once you adopt SMTP reject based on a blacklist then you
accept to stop getting false positives about that traffic, so you
really stop monitoring the effectiveness of that block.

The issue with this is that you have to start building a reputation
not only for IP/domains/other email content fingerprints (sender
stuff), but also need to build a reputation for feedback providers
(recipient stuff) and maybe you also need a reputation management for
people asking delisting (consultant, ESP...)

A lot of data to mix.. so you start building some machine learning to
deal with that automatically and then you end up with SmartScreen and
no one, included your creator, will know why some message have been
blocked or not ;-)   (no offense to SmartScreen, I know how hard is to
deal with this stuff, but I receive Office365 invoices in spam, in my
Office365 inbox.).

An FBL system "ala Google PT" (so only aggregated data not enabling
list washing) but open to multiple receivers could help adding more
accountability to ESP to do their own filtering part (mainly with B2B
emails, as with B2C they already have microsoft/yahoo/google data).

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] sectoor TOR blacklist

[Stefano Bagnara]

On Wed, 6 Jun 2018 at 09:52, Gianluca  wrote:
> Hi all,
> we experience some problems with sectoor.de blacklist, our ips are 
> blacklisted into this list but the main web page of the blacklist 
> http://www.sectoor.de/tor.php is simply a blank page without informations.
> Anyone wih the same problem? Can we consider it a False Positive?

It is listing everything... sounds like the domain expired.
So it is an issue for the receiver: they probably want to remove that
DNSBL from their configuration or they won't receive anything anymore,
from anyone.

Stefano

--
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] spamauditor, ivmuri: how do they collect false positives?

[Stefano Bagnara]

On 9 May 2018 at 18:38, Rob McEwen  wrote:
> Sorry - i just noticed that the hand-typed message we had sent you was from
> 2017 - I had quickly copied and pasted the date and mistakenly assumed it
> was from 2018 - so ignore that part. (but that doesn't change what I stated
> above very much)

The 2017 issue was about *another* domain. At that time you told me
the domain of the sender and I think I fixed the issue as the domain
has never been listed again on your list.

From my logs april 2018 was the first time I tried to delist the
mymailer DOT it domain on your site and I sent 1 delist request and 3
followup emails waiting 1-2 weeks between them with zero answers from
you (not even an ack), then I decided I better spend my resources
trying to get my recipients make complaint because, as you say, when
complaints come only from the sender then no one care because this is
what spammers do. This is not to blame you but to try to be
transparent and prove I'm not a blackhat and I don't want to find
someone to blame between me and you, while I'd prefer to identify the
spammer abusing my platform or, if it was a false positive, find a way
to get this reported by the recipients (as we both care about them).

I know running a blacklist is hard and dealing with delisting request
is a PITA, that's why I posted here trying to talk about something
different from blacklisting/delisting: how false positive reports
happens and flow to blacklist owners.

Stefano

PS: I keep replying here only because this list have public archives
and I don't want an offlist answer to sounds like I have something to
hide. I understand no one cares about those details and I apologize
for this. Rob: if you agree and you want to tell something more about
the delisting you can also write me offline, instead if you have
something to say about the false positive reports collections I still
think we could be in-topic.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] spamauditor, ivmuri: how do they collect false positives?

[Stefano Bagnara]

On 9 May 2018 at 18:21, Rob McEwen  wrote:
> Stefano,
>
> (can't speak for spamauditor... but regarding invaluement...)
>
> (1) To answer the question about "no false positive reports" - The general
> []
> - and while that is just one factor - and other things are considered, too -
> when weeks or months go by and the ONLY delist requests are coming from the
> SENDER - and ZERO are coming from the recipients - and zero are coming from
> their hosters and ISPs who use our data - THAT IS A RED FLAG THAT RARELY
> HAPPENS FOR DESIRED MAIL!

I simply asked how you get false positives: I don't think that this
question is "black hat" or "gray hat".
I do my work, so when someone tells me there are no false positives,
given I think I'm in the good, I try to understand why and try to get
the recipients to do this false positive reports but I don't know
how.

> (2) On April 28, 2017, I replied to one of your messages, provided you with
> much very good information about the cause of your listings, and I delisted
> your domain.

Yes, that case was fixed in short time from me, once I got a reply
(and I got a reply when I CCed you).

> (3) last week, you emailed again - and while I didn't take the time to reply
> (we were overloaded that day) - I gave you the benefit of the doubt and
> immediately delisted your domain (again)

Please note I didn't open THIS topic to discuss about an unreplied
delisting, but to understand how this services receive false
positives.
That said, my message was not last week, but 29 march, then 6 april,
12 april and lastly 6 may.. all of them without answers: I'm not here
telling you have to answer, but when I see this either I think you
dev/null or you ignore me.
If you think I'm a spammer then just ignore me, but still my question
here to the community to understand how false positive is received by
some player is a "good question", I think.

> (4) you make it sound like you've been doing dozens and dozens of unanswered
> requests over months of time - and you make it sound like none of them have
> received a single answer. In fact, fwiw you've used our formal delist
> process 4 times in the past 4 months - and we've take action 3 times to
> assist you: one automated *immediate* delist of your IP, one manual delist
> of your domain with a reply back to you giving you hand-typed detailed
> information, and one silent delist of your domain (not perfect, but FAR from
> the very negative impression I would have had if I had read your post to
> MailOp, and didn't know the rest of the story!)

I'm sorry I didn't got this. Between 29 march and 6 may I wrote 4
messages and I got no replies. If there have been replies then they
have been lost in the way: I'm here to investigate if you think some
message have been lost.
I repeat: I'm not here for the delisting issue, I'm here on mailop to
understand if the blocklists receives the false positives from my
recipients.. If my recipients only have a "mark as spam" and don't
have any way to "mark it as non spam" then it is a bug in your false
positive collections.
I don't think I'm a spammer, and I spend most of my time doing
antispam, so I don't blame you or your "non answers" (you get
thousands of delisting from spammers, I've been there too), and
instead I moved the point to try to understand how to let you get
false positives from my recipients.

> (5) But why are you not being given an even higher priority? And why do you
> keep getting listed?:

I'm all ears if you have suggestions, but this is not the point of my
post here, but given you wanted to bring this in mailop I'll answer
here because I don't want people think I'm greyhat when I work to be
as clean and transparent as possible.

> (A) you're using garbage domains that have zero good reputation - and they
> have home pages that look like a typical snow spammer's domains. EXAMPLES:
> "mymailer DOT it" (with and without the "www.", or even with the "app." host
> name you use on this domain). This isn't a crime, but it is especially a
> good idea for ESPs to NOT use such zero-reputation domains - and even to an
> anti-spam researcher manually checking this, such results don't inspire
> confidence. Why? Because (as happened in this case) when I'm researching
> delist requests and LOOKING for good credibility to justify a delist... and
> the domain being requested has home pages like THAT - it immediately informs
> me that the requester is less worthy of my attention and respect. In
> general, use of "throwaway domains" is not a best practice for ESP.

app DOT mymailer DOT it is a domain used since 2010 for the same use
and sends a couple of millions email monthly. Traffic is steady since
a few years and is shared between thousands of senders in the italian
market.
It has non hidden whois data and I operate it transparently. I'm not
saying 0% spam is sent from that domain, but we do monitor and we do
our best to keep it clean. I kick senders every day. I prevent new

Re: [mailop] GDPR and WHOIS PRIVACY

[Stefano Bagnara]

On 4 May 2018 at 11:27, Andrew C Aitchison  wrote:
> [...]
> If I understand correctly, the GDPR doesn't provide the same protection for
> companies as it does for individuals, so I don't see how it
> can affect role email addresses and registered corporate adddresses;
> those should be able to stay in WHOIS.

Right, but the "Admin/Technical" contacts are named people, and even
their simple Name and surname are data protected by the GDPR.
There are also discussions about "individual businesses" where the
name of the business is the name of the person, so it could be a data
protected by the GDPR.

BTW not every data processing/publication require consent according to
GDPR. There's "legitimate interest" and it may have to be discussed if
publishing that data do harms more than not-publishing it.

This is not trivial, and it will take time to find how GDPR will be
applied as there is an high level of iterpretation in the text. Also
the GDPR is mainly concerned about protection than privacy. Privacy
will be better discussed in the "e-privacy" regulation that should
have been go public together to the GDPR but is still blocked. So we
have an "half-law" with a lot of "will see" stuff... it will take
years to really find the way.

Stefano

> --
> Andrew C. Aitchison Cambridge, UK
> and...@aitchison.me.uk
>
>
>> There are legitimate reasons for anonymous domains, but if there is no one
>> listed to report problems related to that domain, it becomes a problem.  IF
>> you have to be anonymous, send mail out through a mail service that isn't
>> anonymous (eg PTR reflects a domain where there is whois and contact
>> information)
>>
>> And for the record, GDPR did not 'push' for WHOIS to dissappear, the
>> registrars are just concerned that publishing that data in WHOIS may
>> contravene the GDPR.
>>
>> However, the GDPR does allow for personal information to be shared, as
>> long as it is for a legitimate reason, and the person who's information is
>> displayed understands that and agrees to that.
>>
>> Now, if anyone takes that information, and uses in way that wasn't agreed
>> to by the person, (eg a person stripping that data, whether a spammer or a
>> 'data company') it is that party that is contravening the GDPR
>>
>> I expect it (the wrangling and legal arguments) to go on for some time
>> yet, before this is all sorted out.
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Received header address information

[Stefano Bagnara]

On 21 April 2018 at 18:24, John Levine  wrote:
> In article  you write:
>>Am I missing a case where there is a negative outcome to a legitimate,
>>by-the-book sender?
>
> Spammer forges header with address of unrelated network, that network
> gets listed even though it has never sent spam and has no relation to
> the spammer.

This already happens very often with CloudMark Authority and their
"fingerprints" based blocks (and I think the Vipul's Razor
fingerprints too).

For each domain referenced in the email they compute a fingerprint. If
they get spamreports they may list that specific fingerprint.
The owner of the domain have no way to control or limit the usage of
the domain in other emails, but still his domain can be blocked by
cloudmark because it was referenced in a spam email.

Let's say you add a  comment to your spam
email, then CloudMark Authority will block the fingerprint for
mailop.org and every email from this mailing list will start being
blocked by CloudMark Authority because of the block. The fingerprint
will become "controversial" if they also measure an high number of
people moving the email from the spam back to the inbox, but in the
mean time you get them in spam. So this is very prone to black-hat
abuses, but given how popular is Cloudmark Authority today I'd say the
abuses have not been so problematic and black-hats put their efforts
elsewhere.

Domains are only one of many things being fingerprinted by Cloudmark
Authority and you recognize them as being postfixed by ":8" in the
X-CNFS-Analysis header (or similar).

In Italy Cloudmark Authority affect an average of 30% of recipients,
much more than Hotmail and Yahoo filters, comparable to Gmail filter.
As we get used to this behaviour the "arguments" in this thread are
not so weird as one may guess.

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Hat color of list washers / validators

[Stefano Bagnara]

According to Talos it could be safe to block the whole /19 as I can't
see other senders that could be involved:
https://www.talosintelligence.com/reputation_center/lookup?search=63.250.0.0%2F19
Thousands of IPs in the block follow the same naming patterns...

According to Arin:
https://whois.arin.net/rest/net/NET-63-250-0-0-1/pft?s=63.250.13.148

It is allocated to Webhosting.Net, Inc., Miami:
https://whois.arin.net/rest/org/WEBHOS-10

And here are other nets assigned to the same entity:
https://whois.arin.net/rest/org/WEBHOS-10/nets

Maybe it worth checking traffic from the other networks, too.

Stefano

On 9 March 2018 at 15:47, Al Iverson  wrote:
> Wow, those IPs have really poor reputations. I'm curious to know who
> this is if you end up figuring it out.
>
> Smells like an email validation service. Very disappointing that the
> domains vary and are ownership info is hidden from public view.
>
> I've had one such vendor tell me that they don't care if they get
> blocked, they'll just spin up more IPs and domains. It was a while
> ago, though, I don't recall which vendor it was. Pretty unethical,
> though, in my opinion.
>
> Cheers,
> Al Iverson
>
> On Thu, Mar 8, 2018 at 8:39 PM, Michael Peddemors
>  wrote:
>> Speaking of..
>>
>> Does anyone know this actor?
>> Is this a list washing service..
>>
>> Lot's of 'invalid users' however, large amounts of email at once to those
>> invalid users.. Fairly big IP Space..
>>
>> 63.250.8.14   1   william1.expedite.scanprofile.net
>>63.250.8.191   liam2.epromo.scanprofile.net
>> 63.250.10.16  1   janus1.min.metricgeneral.com
>> 63.250.11.15  1   hera1.display.verifymetric.net
>> 63.250.12.18  1   hephaestus.min.profilescan.net
>> 63.250.16.12  2   ethan.verify.scanverify.net
>>63.250.16.14   1   alexander1.erep.scanverify.net
>>63.250.16.20   1   zeus.min.scanverify.net
>> 63.250.17.15  2   noah1.rev.livelymetrics.com
>>63.250.17.21   2   hera1.pursue.livelymetrics.com
>> 63.250.19.13  1   hypno.mind.profileinquiries.com
>> 63.250.20.13  1   adv.edisplay.activeinquiries.com
>>63.250.20.14   1   ares2.fuse.activeinquiries.com
>>63.250.20.16   2   net1.broadcast.activeinquiries.com
>> 63.250.21.18  1   hephaestus1.sponser.livelyscan.com
>> 63.250.22.14  1   central1.tech.scangeneral.net
>>63.250.22.20   2   hera.verify.scangeneral.net
>> 63.250.23.12  1   thor1.edisplay.scanprofiles.com
>>63.250.23.13   1   bishop2.edisplay.scanprofiles.com
>>63.250.23.14   1   ares1.long.scanprofiles.com
>>63.250.23.16   1   main2.ediscover.scanprofiles.com
>> 63.250.24.14  1   names2.mind.metricsverify.com
>> 63.250.25.17  1   main2.digital.scangeneral.com
>> 63.250.26.14  1   hera2.effect.verifyscan.net
>> 63.250.27.17  1   names2.live.activemonitor.net
>>63.250.27.21   1   nemesis2.edirect.activemonitor.net
>> 63.250.28.15  1   nemesis.transaction.profilemetric.net
>>63.250.28.16   1   elijah.note.profilemetric.net
>>63.250.28.17   1   janus2.note.profilemetric.net
>>63.250.28.19   1   net.tech.profilemetric.net
>> 63.250.29.13  1   prime.edrive.activeprofile.net
>>63.250.29.16   1   ironman1.question.activeprofile.net
>>63.250.29.20   1   main.action.activeprofile.net
>> 63.250.30.21  1   net2.relay.profileverify.net
>> 63.250.31.15  1   irishecate.secure.metricgeneral.net
>>63.250.31.18   1   demeter.remark.metricgeneral.net
>>63.250.31.19   1   poseidon.remark.metricgeneral.net
>>
>
> --
> al iverson // wombatmail // miami
> http://www.aliverson.com
> http://www.spamresource.com
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Hat color of list washers / validators

[Stefano Bagnara]

On 8 March 2018 at 16:14, Laura Atkins <la...@wordtothewise.com> wrote:
> On Mar 8, 2018, at 1:18 AM, Stefano Bagnara <mai...@bago.org> wrote:
>> PS: that trendmicro article is a bit the opposit of Laura answer I got
>> yesterday about "dealing with it offline because making it public is
>> not the way to fix the issue" ;-) I liked that article in 2011.
>
> I don’t believe I ever said “dealing wit it offline because making it public
> is not the way to fix the issue.” But it you can show me where I said that,
> I will happy correct it.
>
> I did say a couple things about making issues public, including:
>
> "Talking about it on a public mailing list is very different from addressing
> the issue. In fact, I’d say public discussions are a last resort.”

The sencence I was referring to is the one that you just quoted above.
As a non english speaker my "rewrite" didn't sound so difference in
substance, and I didn't think it was important enough to lookup the
history and quote word by word.

> In a different email I said:
>
> "But, it’s kinda a big deal to call out stuff like this and while we’ve
> called out blocking companies / blacklists in the past, I’m not in a
> position where I think that will provide an overall benefit by making the
> information public. It’s also not like I’m the only person who knows this.“
>
> Please either prove or correct your statement.

It is bad to cite in a wrong way, so please accept my apologies for
incorrectly quoting something you told or for having misunderstood
your statement.

Stefano

PS: I replied in-list because you asked for a correction, and you
deserve a public correction, but I think we are going offtopic, I'll
try to stop the flame.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Hat color of list washers / validators

[Stefano Bagnara]

On 8 March 2018 at 02:43, Steve Atkins <st...@blighty.com> wrote:
>> On Mar 7, 2018, at 4:38 PM, Stefano Bagnara <mai...@bago.org> wrote:
>> Let's take into consideration that spamtrap network have to do their
>> homework to avoid being identified easily, so if they never do
>> opens/clicks they already put a big flash on them. So I think it is OK
>> for a spamtrap to open/click or even reply to an email, but it is
>> important that the email address has been in a "user unknown" state
>> for at least 1 year (or something similar).
>
> No. Never. If you do that then the address is tainted and you
> *cannot* legitimately use information as it as evidence that mail
> sent to it was unwanted.

This is not the place, but I strongly disagree (but is something very
subjective, I admit).

Opening a message is not a proof of consent or anything else: it is
just something used by marketers to track performances.

If you have COI then, every few months you sent emails with
unsubscribe links and without bounces, then you have the proof and the
spamtrap would be not legitimate.
But if there is no COI or you have a big 1 year hole in your sends
since you had your COI then you lost your consent.. fake opens are not
a "renew of consent".

I don't run spamtraps (I have no current relationship with people that
do), now, but I see opens and clicks from spamtraps operated by very
serious people and I don't think they are wrong with that.

> You can still use it for quite a few
> interesting things, but you can't use it as a spamtrap (unless
> you want to spend another year rejecting everything).

Why? I hear your strong on your opinion, but I don't get why you think
it is wrong and that an open should invalidate a spamtrap.
So, if I send a sample message received to a spamtrap and reviewing
that message I look at images, then I have to invalidate a spamtrap?

> I talked about this at some length about six and a half
> years ago. It wasn't a new problem then.
>
> https://wordtothewise.com/2011/08/a-disturbing-trend/

Clicking a confirmation link is different from doing some fake opens
and some fake click: so, if they clicked a confirmation link then I
agree it is bad and not legitimate. But opens or other clicks are not
controversial, they are simply legitimate fake behaviour.

BTW there are antivirus that will click every link they found, so
tools that rely on one-time-link-clicks sent via email to do
confirmations (see also the list-unsubscribe issue in another thread)
should take one more step on the resulting website in order to
complete the confirmation. Otherwise some antivirus/antispam will
confirm opt-ins without user-consent (and this is an issue, bigger
than the bad spamtrap issue).

About Trendmicro I never saw them clicking a confirmation link, but I
confirm I saw them using expired domains without the 6-12 months
reject period. Well, trendmicro (at least in past) listed you even if
it received only the COI request email to some of their spamtraps.

PS: that trendmicro article is a bit the opposit of Laura answer I got
yesterday about "dealing with it offline because making it public is
not the way to fix the issue" ;-) I liked that article in 2011.

So, given clicks are controversial: can we agree that a good spamtrap
is safe to emulate opens? Or do you see issues with that too?

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Hat color of list washers / validators

[Stefano Bagnara]

On 8 March 2018 at 01:02, Laura Atkins  wrote:
> [...]
> Sure, we agree. But there are folks who don’t agree with us. Some of those
> folks run spamtrap networks that feel blocklist data. I think it’s important
> to acknowledge that. At one point you could do COI and still get on a
> blocklist because you sent to a spamtrap.

That's why we need to find someone that is able to share real bits on
the issues (who's who).

We can't expect a provider to fix a bad habit (or to publicly explain
there was a bug) if no one talks about it and people keep buying its
services ignoring those issues.

If they feed a blocklist like that and I buy a blocklist that is fed
that way I'd be very disappointed.

If they do that sistematically then they will create a lot of false
positives and blocklist users will start complaining.. so I really
hope/guess we're talking about a bug.

> At one point you could do COI and
> mail to folks who’d only opened an email in the past few weeks and still get
> on a blocklist because you sent to a spamtrap. This affected real senders
> who weren’t spamming.

Just to make this more interesting, I think this may have a slighly
different "story" that may be "right".

2014: I collect the addr...@example.com email address

2015: the example.com domain expires, is bought by the spamtrap
network that starts returning 511 this will become a spamtrap for 365
days.

2017: I decide to send an email to that address for the first time, I
hit the spamtrap. Some network doesn't report back your first hit,
instead they sometimes make opens/clicks, I don't know if they do that
to simulate traffic or for some other reasons.. (hint: I saw
clicks/opens from antivirus/antispam cloud providers IP spaces, but I
don't know the reasons).

2 weeks later I send a second email only to people that opened in the
last month, and addr...@example.com is reported, correctly, as a
spamtrap hit.

So, it was COI, and I was writing only to openers from the last month,
and still I hit a "3 years old repurposed spamtrap".

Let's take into consideration that spamtrap network have to do their
homework to avoid being identified easily, so if they never do
opens/clicks they already put a big flash on them. So I think it is OK
for a spamtrap to open/click or even reply to an email, but it is
important that the email address has been in a "user unknown" state
for at least 1 year (or something similar).

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Hat color of list washers / validators

[Stefano Bagnara]

On 8 March 2018 at 00:08, Laura Atkins  wrote:
> [...]
> I don’t either, but I am not fighting language with folks.

I'm sorry Laura. My mother language is not english and your "tone" is
unexpected to me, so I probably used wrong translations for my
questions.
No need to fight anything.. I'm just discussing in a list and trying
to give and get back like I always do.

> [...]
> I have, and know other people who have, and again, this was discussed
> earlier this month at M3AAWG.

I'm not in M3AAWG, but I hoped that some info that can be shared in
the M3AAWG could be anonymized and shared here too.
If this is not the case, then ok, I just asked. Maybe someone else
will feel to share something.

> But, it’s kinda a big deal to call out stuff like this and while we’ve
> called out blocking companies / blacklists in the past, I’m not in a
> position where I think that will provide an overall benefit by making the
> information public. It’s also not like I’m the only person who knows this.
>
> In one instance with a client, they were using one of the aforementioned
> delivery monitoring companies and saw a “pristine trap" hit. They were able
> to identify the specific address as the company provides the full text of
> the message. They had recent (within a few weeks) click data from that
> address and a purchase within a few months.

OK so if I got it right then these "delivery monitoring" spamtraps are
not really used by anyone but the delivery monitoring service itself.
It helps the paying ESP/ISP to identify problematic senders in their
network and they also need spamtraps for them.. maybe they have too
few of them so they have been a bit "easy" introducing new domains to
have more data to monetize.

In this case either they had a bug, needs to better document how they
create spamtraps or they are "abusing" their customers trust.
We can agree that it is hard to define what can be a spamtrap and how
many months are needed for them to become spamtraps, but I think we
all agree that a valid/working inbox can't become a spam trap in a
week.

>> Can you give some hint about the spamtrap network?
>
> I did, in the original paragraph.

OK, thank you.

> [...]
> I don’t keep that information around. I don’t want to know what traps are. I
> don’t want to know what domains traps are using. Overall, I don’t want to
> have that trail. I can’t reveal what I don’t record. When I do run into a
> trap or set of traps or domains I just let it be forgotten.
>
> If that makes me untrustworthy to you, I totally understand. I’ve given you
> no reason to believe me and here I am refusing to give you a reason or
> examples. Even worse, I am making very logical arguments about why I may not
> have kept said evidence. I get why you don’t believe and don’t want to
> believe. The best I can hope for is you’ll keep an open mind and look
> through your own data and test data you have to see if you can confirm it.

No problem Laura, thank you anyway for you great contributions to this list!

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Hat color of list washers / validators

[Stefano Bagnara]

On 7 March 2018 at 22:52, Laura Atkins  wrote:
> There are companies that have commercialized spamtraps and at least 2 of the
> delivery monitoring companies will tell you when you’ve hit a trap.

Sure I know.. that's why I'm asking what is the network.
If someone sells spamtrap hits data and the spamtraps are 1 day old
while they declare they are at least 1 year old then I think it worth
sharing.

> In other
> cases, some compliance folks will data mine to find spamtrap domains when a
> blacklist is telling them that they are listed due to spamtrap hits. I’m
> pretty sure I’m not the only person who has identified various spamtrap
> accounts over the years.

I probably made my questions using the wrong words... I know *a lot*
of spamtraps and spamtrap networks.
Then I know a lot of "do something else with expired domains" networks
that have no effects on reputations or blacklists, so I don't consider
them spamtraps, but blackholes.

I never seen the behaviour you describe from one the spamtrap networks
that I know sell their data or I know have impact on reputation
somewhere. That's why I was courious.

> In one instance with a client, they were using one of the aforementioned
> delivery monitoring companies and saw a “pristine trap" hit. They were able
> to identify the specific address as the company provides the full text of
> the message. They had recent (within a few weeks) click data from that
> address and a purchase within a few months.

Can you give some hint about the spamtrap network? I don't need the
full name website or anything else, just something that let someone
that know the spamtrap networks understand who you are talking about.
Did the spamtrap network publish a document about how they classify
their spamtraps? Some of them do and clearly states how many months
they keep a 5xx error before turning the domain into a spamtrap.

> Folks I trust have also shared similar stories with me. Addresses that are
> traps show click activity the week before.

I hear many folks sharing many stories.. unfortunately House told me
that everybody lies, so I always try to verify, when I can.

> No, I don’t have permission to share examples. But this was discussed at
> M3AAWG earlier this month and multiple people confirmed they had evidence.

No need for full examples.. md5/sha1 of the lowercased domain or
md5/sha1 of the first lowercased mx server or md5/sha1 of the IP that
received the email would be enough to share your knowledge only to
others that already know about the network.

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SCL Rating Level of consideration at Hotmail

[Stefano Bagnara]

On 7 March 2018 at 20:48, Tony Rose  wrote:
> Does anyone on the list know how much creedence the Outlook Deliverability
> Support Team puts into the Spam Confidence Level?
>
> I have seen quite a few messages still get filtered into the junk folder
> with a SCL of 1.

AFAIK an High SCL may cause your message to be classified as junk, but
not viceversa.
Also an High BCL may cause your message to be classified as junk, but
not viceversa.

There are indipendent factors: being safe on one of them doesn't save
you from the other scores/filters.


Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Hat color of list washers / validators

[Stefano Bagnara]

On 7 March 2018 at 20:25, David Carriger
 wrote:
> In the worst examples I've seen, the domain went from a legitimate mail
> server to a trap network in the same day, with no time for bounces in
> between.

Are you 100% sure? Which trap network? How did you find it was a trap?
Can you share anything so that we can check for similar occourences
and look for third party confirmations?

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Hat color of list washers / validators

[Stefano Bagnara]

On 7 March 2018 at 13:20, Ken O'Driscoll via mailop  wrote:
> There are some industries where offline data acquisition is the norm and
> validation is seen as part of the data quality process.

"norm" is not so good as a "valid" reason:
- what's the point of *validation* for these industries?
- what do they get from "cleaning" using a list validation service
that they cannot get by simply sending and analyzing errors?

The first answers I can think about all points to prevent the receiver
MTA to classify you as spammer by hiding your dirty clothes, and this
sounds more dark than light...

1) Most validation service apply a pricing that is higher than what it
will cost to send a real email
2) If their offline acquisition is so bad to require a validation to
avoid spam filters then they are probably extoring the email address
in the process or needs a better way to collect the email address
because if the validation prune stuff, it means they are loosing money
collecting fake data.,. so the cure is not the validation.
3) We could open a big topic about the quality of this validation
services: have you ever tried cleaning a list of your active/working
email addresses? I did and the result was a disaster (working and
engaged emails removed, spamtraps that I added to the list by purpose
left in). So, when they clean, at least with some of the services I
tried, they remove also valid recipients. (e.g: some of them removed
my own @apache.org valid email address as a spamtrap)

As per GDPR if you collect offline data and you will pass this data to
an email validation service then, when you acquire their consent, you
will also have to tell them the email validator service that will
receive their data, then you also have one more data-processor to take
into account into your GDPR diligence... So, don't move the personal
data around to third parties unless this really gives you a real gain.

Sending a confirmation email using the same tool that you will use to
send the communications for which you acquired their consent in the
first place will be enough and will work fine without the need for a
validation service.

Even if you collected the email offline and in bulk, there will be
some moment in future when you will have to send an email to them,
right? So
- if you want the email address (and the "consent") to be confirmed
send a "confirmation request email" and this will also validate the
email.
- If you don't like COI then let your fist email to be the "validation".
- Even if you don't like COI I suggest you to send an email to inform
them their address has been transcripted and give them a fast way to
tell you that they are not the right recipients and you trascripted a
wrong email.

All of them sounds better than a "third party validation", if you work
in the "consent-based" world.

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Hat color of list washers / validators

[Stefano Bagnara]

On 2 March 2018 at 21:45, John Johnstone
 wrote:
> [...]
> It seems somebody gave some fairly purposeful thought into coming up with
> the algorithms to generate these.  I'm curious to know what peoples thinking
> is as to the hat color of these attempts.  Particularly if there are any
> opinions on the risk / need to block them.

Tools like hunter.io try to suggest you the "pattern" used by a
company so that you can guess email address for named people, but they
mainly use crawled data, so I think your suspect is findanyemail.net:
put a name and surname and your domain and it will try to guess the
patterns and "verify" them.

That said, about the hat color

We're a small ESP and I think email validators/cleaners are making OUR
life harder.

We can identify bad clients/customers as soon as they load their list
if it contains very old expired domains, spamtraps, fake domains,
emails like "e...@ail.jpg" or some .pdf TLD. Or we can identify "non
confirmed" lists because of the presence of many typos domains. This
let us block and vet the senders BEFORE they abuse our tool (and send
spam).

But if they come with a cleaned list then it is harder for us and we
have to do the first send in order to understand they are spammer, and
sometimes when they have mostly b2b addresses it is hard because of
missing FBLs from the providers and very low feedback from recipients
that know it is spam.

I think that from a receiving MTA point of view, this is the same: if
they hit your spamtraps (or simply invalid recipients) you have more
chance to deal with them "correctly" and early.

So, from our point of view, bulk list validators are bad and I can't
see a valid point to use them, but trying to trick the game (for short
term spamming results).

That said, some ESP have a different opinion from me, as I just read
this recent post:
https://www.campaignmonitor.com/blog/email-marketing/2018/03/verifying-emails-win-win-email-marketing/

I'm interested in how receivers see this email verification tools and
how many of them deployed protections from them (e.g: identify their
IPs and refuse or fake the answers to their requests or anything
else).

Stefano

PS: between the many email verification tools, Kickbox
(https://kickbox.com/about) have a claim "Kickbox is a white hat
service provider".

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] TLS support

[Stefano Bagnara]

On 22 February 2018 at 17:00, Stefano Bagnara <mai...@bago.org> wrote:
> We ignore certificate issues and lowered the cypher requirements as
> much as possible.
> We settled to 0.01% failures converting the socket to TLS: most common
> domains involved in the failure are uni-kl.de and univie.ac.at

Just an update because Univie postmaster kindly contacted me offlist
and we analyzed the issue.

Turned out my MTA did not support EC* ciphers so when contacting
uni-kl or univie servers the TLS handshake chose (server chosen) a
DHE_ cipher.

The issue is that both serve use a DH key length that is not "multiple
of 64" (1453bits the uni-kl, 2236bits the univie) and Java fails with
this error "DH key size must be multiple of 64, and can only range
from 512 to 8192 (inclusive). The specific key size 2236 is not
supported".

I'm not a cripto expert so I don't know if this "multiple-of-64"
constraint from Java is a java limit or a cipher specification.

Now, enabling the ECDHE_ ciphers on my side worked around the issue.
It seems the DHE_ cipher have a "limit" because when 2 parties choose
to use it they don't know yet if they will be able to complete the
handshake, while EC* expose the supported curves in the choice phase
so you better know the handshake will work if you agree on that
cipher. I found this article:
https://groups.google.com/a/chromium.org/forum/m/#!topic/blink-dev/AAdv838-koo/discussion

I found many receivers (microsoft, gmail, yahoo) only expose ECDHE_*
and not DHE_* ciphers maybe because of this issue.

Even if enabling ECDHE seems to have fixed most of the remaining
issues, I'm evaluating removing DHE_* ciphers on my client side to
avoid further issues similar to this.

I found https://github.com/mozilla/cipherscan useful, while debugging the issue.

Hope this helps,
Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] The "goo.gl" shortner is OUT OF CONTROL (+ invaluement's response)

[Stefano Bagnara]

On 21 February 2018 at 09:44, Philip Paeps  wrote:
> [...]
> Following JavaScript redirects is probably all but impossible except for the
> simplest case because of the halting problem.  Unless you want to execute
> the JavaScript ... and down that road lies madness.
>
> Seems a lot more expedient to consider the mere presence of JavaScript as a
> strong indicator of spam. ;-)

Presence of javascript in the page resulting from an URL linked in the
content of an email as an indicator of spam??
I guess 99% of pages linked in email contains javascript, like most of
the WWW. So you will junk every email with a link ;-)

IMHO if the redirect service uses "hidden ways" to do redirect then
you are safe to put the reputation score on the redirecting domain
itself: no need to deal with javascript at this "level".

One more cent for the thread:
Redirects is possible not only in HTTP or with javascript, but also with HTML:


Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] VERP in 2018 (Was: RoadRunner Help?)

[Stefano Bagnara]

On 19 February 2018 at 12:24, David Hofstee <opentext.dhofs...@gmail.com> wrote:
>>Using a return-path in the domain of your customer can be easy when
>>you have a multi-thousands-dollars contract for each customer. But
>>when you have "free" users or "few dollars per year" customers, you
>>can't afford manually helping people to configure their domains so
>>that you can use that in the return-path and then deal with major
>>issues when the domain is "misconfigured" during a send
>
> Why would you need to "manually help" people? SPF and DKIM can
> be automated. Customers only need instructions for 3 DNS records.
> Verification of those settings can be automated.
>
> In MailPlus you can request this SPF/DKIM setting verification page:
> https://drive.google.com/open?id=0B3Pxi9-uQ2MtbUdNeDByR3hqcTRHY2NyMk4zUVJscTh2clFr

Are you telling me that none of your customers needed help with that?
Your customers probably have an IQ above average! How many
customer-support people do you have for every 1000 users of the
platform?

My users have issues identifying a button when there is only one
button in the whole page, so we are very dedicated to UX. They don't
even know who/where to go to alter DNS of their own domain, and there
are plenty of providers with their own tool to deal with DNS entries.
We work a lot on helpdesk and for every step you add, even the most
trivial, we will get more requests.

Last time I checked most big freemium ESP let you do this
configuration as an option, but they also let you send without
altering your DNS: maybe they shared my concern.

> It checks if your DNS settings are ok, validate if DMARC settings are not
> too restrictive and will setup SPF/DKIM automatically if they are. Signing
> is done in Java (and not on the mta). No hands needed anymore.

Then maybe you use my opensource Apache jDKIM library? ;-)

Stefano

>
> Yours,
>
>
> David
>
>
> On 18 February 2018 at 00:53, Dave Warren <d...@thedave.ca> wrote:
>>
>> On 2018-02-17 03:48, Stefano Bagnara wrote:
>>>
>>> Unfortunately there are still some server accepting everything and
>>> sending bounces without headers or malformed bounces.
>>
>>
>> This is not a small group. Every few months I get massive floods of
>> bounces from some spambot that decided forging my domain is a good idea.
>>
>> I didn't even realize this was still a thing when I was running my own
>> mail server as I've used something similar to BATV for years. But after
>> switching my personal to a host that doesn't use this technique I have begun
>> to realize just how much garbage goes flying by out there.
>>
>>
>>
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>
>
>
> --
> --
> My opinion is mine.
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] the joys of VERP, was RoadRunner Help?

[Stefano Bagnara]

On 17 February 2018 at 18:46, John Levine  wrote:
> In article 
>  you 
> write:
>>The use of IDs instead of the real original email in the return-path
>>may also be because of length limits.
>>Max length of an email address is 254 chars. If you have to insert it
>>"almost clear" in a return path and change the domain then there are
>>chance your return-path address will be more than 254 chars.
>>so if your original address is "a 242 ti...@example.com" how do you
>>add VERP to it without some sort of obfuscation?
>
> Actually, you're more likely to hit the local-part limit of 64 first,
> but how many real addresses (as opposed to artificial stress tests
> ones) have you seen where that's a problem?

It was 15 years ago and you're probably right we hit the limit of the
64 chars in the local part before the 254 of the full email.
I don't remember how often it happened, but this prevented delivery of
messages (or breaking the bounce processing by truncating the
address), so, even if they were 1 on 100.000 it needed a fix (and it
was using internal identifiers).

From a fast grep 0.05% of the email logged in my MTA are 40 chars ore
more in length. 0.0002% is more than 50.
Add your own return path domain length (in our case it was 17 chars,
18 with the @) and maybe some other prefix (it was a "b+" in our case)
and you get the volumes.

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] RoadRunner Help?

[Stefano Bagnara]

On 17 February 2018 at 17:21, Al Iverson  wrote:
> []
> I am saying that I think it's unwise to put what amounts to
> subscriber-level PII or basically clear identifiers in the Return
> Path/MFROM, if mail back to that address is interpreted as an
> indication that an action should be taken (like logging a bounce and
> potentially stopping future mail to that recipient). It's an open slot
> where an external actor could insert something to cause actions beyond
> the expected ones. That counts as a security concern in my book.
>
> Yes, it is personally reasonable that different people will have
> different takes on the level of concern associated with that potential
> risk.

A good practice is to protect your VERPs with a signature (BATV or
something similar may work).
This is valid for both clear and obfuscated VERP paths.

The use of IDs instead of the real original email in the return-path
may also be because of length limits.
Max length of an email address is 254 chars. If you have to insert it
"almost clear" in a return path and change the domain then there are
chance your return-path address will be more than 254 chars.
so if your original address is "a 242 ti...@example.com" how do you
add VERP to it without some sort of obfuscation?
So, once you HAVE TO use some sort of obfuscation for long address,
why should you prefer using 2 different algorithms? The obfuscated
solution works for both short and long addresses.

Also maybe we could differentiate between VERPs where the MAIL FROM
simply depends on the recipient email address and VERPs where the MAIL
FROM identify a single sent email (so if the same sender send another
email to the same recipient using the same server the mail from smtp
will be different). The give you 2 different level of "protection" and
2 different levels of "issues":

BATV puts you in the second group, help you with backscattering, but
don't help with deliverability where some recipient cannot whitelist
you because their whitelist work on the return-path address and it
changes every time.

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] VERP in 2018 (Was: RoadRunner Help?)

[Stefano Bagnara]

On 17 February 2018 at 14:23, Benjamin BILLON <bbil...@splio.com> wrote:
> My 2cents: some ISPs require a manual registration based on the MAIL FROM 
> email address (not just the domain name), hence VERP can't be used for them.

Hi Benjamin,

Interesting, can you elaborate? real ISP example?
What does it happen if you "don't register" and how does registration happen?
Are you talking about personal whitelisting? Or that "fill in this
captcha to confirm you are not a spammer to authorize future
deliveries from your address"? Or what else?

I know some ISP per-inbox whitelists works on the MAIL FROM, so if you
use VERP you can't get the whitelisting benefits, but beside that I'm
not aware of deliverability issues due to the use of VERP.

Stefano

> --
> Benjamin Billon
>
> -Original Message-
> From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Stefano Bagnara
> Sent: Saturday, 17 February, 2018 18:48
> To: mailop <mailop@mailop.org>
> Subject: [mailop] VERP in 2018 (Was: RoadRunner Help?)
>
> On 17 February 2018 at 02:19, Michael Peddemors <mich...@linuxmagic.com> 
> wrote:
>> [...]
>> And since the direction most MTA's go is to reduce any form of
>> 'bounce' or backscatter, the idea of using the VERP to detect
>> 'bounces' is probably not as important as it once was, unless the
>> emails are forwarded or client side
>> bounces)
>
> "Non as important as it once was" does not mean the same of "it is harmful".
> I can agree that VERP is less effective than 10 years ago, but still it is 
> the best way to detect some non deliverable email address.
> Without VERP a small percentage of underliverable keep generating bounces 
> that you can't associate to any address.
> The main reasons for VERP to be less important today are:
> 1) much more receivers try to fail "in protocol" (but there are still many 
> that do not)
> 2) much more bounces include the headers for the bounced message (and if you 
> have the headers and you can parse them then VERP is not needed anymore.
>
> Unfortunately there are still some server accepting everything and sending 
> bounces without headers or malformed bounces.
>
>> I personally believe that verp_respo...@esp.com is 'not' what good
>> ESP's should be doing, they should clearly reflect whom they are
>> sending for in the MAIL FROM, whether that be distinctive domain
>> representing whom the emails are for, or even better the person that it is 
>> sending for.
>>
>> When a large operator sends millions of emails all with the same VERP
>> style/pattern, it does a disservice.
>>
>> Now, of course some (and not going to point out names here) ESP's
>> actually like the VERP method, because if they have ONE too big to
>> block company they represent, they can use that as an excuse to have
>> companies whitelist their @esp.com domain, allowing a higher delivery
>> account for all the other less clean lists and senders..
>
> I don't think it is fair to think the reason ESPs use VERP is this one.
> Neither they use @esp.com for this reason.
>
> Most ESP put "per customer identifications" in the headers (most time it is 
> List-ID, some have their own header.. but they don't try to hide the sending 
> customer): you can block the mime from, or you can block via list-id.. so the 
> "too big to block" doesn't see a very strong argument.
>
> Using a return-path in the domain of your customer can be easy when you have 
> a multi-thousands-dollars contract for each customer. But when you have 
> "free" users or "few dollars per year" customers, you can't afford manually 
> helping people to configure their domains so that you can use that in the 
> return-path and then deal with major issues when the domain is 
> "misconfigured" during a send.
>
> AFAIK, VERP has been introduced to deal with mailing lists issues and not by 
> some evil-ESP group.
>
>> I think that transparency is important, and allows for the recipient
>> to make more informed choices as to the emails they want and don't want.
>
> Have you ever tried to look at the List-ID header and other headers?
> Also, most ESP don't alter the "mime from", so you can work on that for your 
> reputation/spam.. if an ESP customer changes the mime from at every send and 
> their ESP let them doing that to avoid spam filters then I suggest to ban the 
> ESP. In the end, like any other sender (ESP are not so special), you will 
> monitor some "rates" and decide if the sender is doing his antispam/antiabuse 
> duties or not.
>
>> Of course, this is ONLY my personal opinion.. The world 

[mailop] VERP in 2018 (Was: RoadRunner Help?)

[Stefano Bagnara]

On 17 February 2018 at 02:19, Michael Peddemors  wrote:
> [...]
> And since the direction most MTA's go is to reduce any form of 'bounce' or
> backscatter, the idea of using the VERP to detect 'bounces' is probably not
> as important as it once was, unless the emails are forwarded or client side
> bounces)

"Non as important as it once was" does not mean the same of "it is harmful".
I can agree that VERP is less effective than 10 years ago, but still
it is the best way to detect some non deliverable email address.
Without VERP a small percentage of underliverable keep generating
bounces that you can't associate to any address.
The main reasons for VERP to be less important today are:
1) much more receivers try to fail "in protocol" (but there are still
many that do not)
2) much more bounces include the headers for the bounced message (and
if you have the headers and you can parse them then VERP is not needed
anymore.

Unfortunately there are still some server accepting everything and
sending bounces without headers or malformed bounces.

> I personally believe that verp_respo...@esp.com is 'not' what good ESP's
> should be doing, they should clearly reflect whom they are sending for in
> the MAIL FROM, whether that be distinctive domain representing whom the
> emails are for, or even better the person that it is sending for.
>
> When a large operator sends millions of emails all with the same VERP
> style/pattern, it does a disservice.
>
> Now, of course some (and not going to point out names here) ESP's actually
> like the VERP method, because if they have ONE too big to block company they
> represent, they can use that as an excuse to have companies whitelist their
> @esp.com domain, allowing a higher delivery account for all the other less
> clean lists and senders..

I don't think it is fair to think the reason ESPs use VERP is this one.
Neither they use @esp.com for this reason.

Most ESP put "per customer identifications" in the headers (most time
it is List-ID, some have their own header.. but they don't try to hide
the sending customer): you can block the mime from, or you can block
via list-id.. so the "too big to block" doesn't see a very strong
argument.

Using a return-path in the domain of your customer can be easy when
you have a multi-thousands-dollars contract for each customer. But
when you have "free" users or "few dollars per year" customers, you
can't afford manually helping people to configure their domains so
that you can use that in the return-path and then deal with major
issues when the domain is "misconfigured" during a send.

AFAIK, VERP has been introduced to deal with mailing lists issues and
not by some evil-ESP group.

> I think that transparency is important, and allows for the recipient to make
> more informed choices as to the emails they want and don't want.

Have you ever tried to look at the List-ID header and other headers?
Also, most ESP don't alter the "mime from", so you can work on that
for your reputation/spam.. if an ESP customer changes the mime from at
every send and their ESP let them doing that to avoid spam filters
then I suggest to ban the ESP. In the end, like any other sender (ESP
are not so special), you will monitor some "rates" and decide if the
sender is doing his antispam/antiabuse duties or not.

> Of course, this is ONLY my personal opinion.. The world is not perfect,
> but the ESP's who are sending with clear transparency are going to enable
> their legitimate email to have a lot higher success rates.

I'm not sure this would really happen to be true. Real world antispam
filters are not that perfect too ;-)
BTW I don't think that "ESP" in your arguments are worse than "any
sender": doesn't the transparency argument apply to non-ESP senders?

Do you manage any bulk sending service? Even a mailing lists would
apply. If you don't use VERP, don't you see that kind of
unidentifiable bounces I described above? How do you deal with them?
Do you force re-confirmation of each recipient every few months? (are
your sending-customers happy with that?).

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Hotmail/Outlook feedback loop processing delay?

[Stefano Bagnara]

On 10 January 2018 at 08:16, Sotiris Tsimbonis  wrote:
> [...] They did
> not report it as spam yesterday, they only viewed it. They don't use an
> email client, they only use the web interface provided by hotmail.

I often heard story like this... the fact is that this "i never marked
it as spam" is always from a non-techie person..
- Sometimes they lie, because they didn't know you spy on their
"junking habits", so they simply deny when you ask why they did
something they didn't know you could "monitor".
- Sometimes they don't even know what is the spam button (some of them
think it is like trash, some of them don't know at all).
- Sometimes they happen to click on stuff without really recognizing they did.

We run a SaaS and very often our users say they never did something
until we dig in the logs and have evidence they really did that, so my
first think is always "everybody lies" (sometimes they are not really
aware they are lying, they simply never read/tried to understood and
thought that "permanently delete" means "hide this for a while").

It is possible there is a bug in the platform, but I still have to get
similar reports from a trusted source or see the behaviour with my
eyes. So, I think you should take this at least as an option (and use
Occam's razor).

> So it's not bulk moving emails to junk using imap. Opening the email
> yesterday triggered the fbl process somehow.
>
> I'm still not quite certain of how it works, but Mihai Costea also
> posted that 1% of their fbl reports are back from 2016 ...

I don't see anything weird from that. People can mark as spam any
email, even if the email has been received a lot of time ago.
He told that he searched the email, maybe they also marked it as spam:
this kind of action could have the legitimate result to send an FBL
for an old message.

It sound like an expected distribution:
0.1% per month (1% in 10 months) 2 years ago
0.4% per month (4% in 10 months) 1 year ago
2.5% per month (5% in 2 months) 3 months ago
90% per month (90% in 1 the last month).

If you do open-tracking you can see similar distributions with
messages being opened even after many years. If they are opened after
years there's nothing weird to see they are sometimes also marked as
spam after years.

Stefano

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Issue with Gmail Postmaster

[Stefano Bagnara]

In my GPT I see the same identical reports whichever domain I select.
So maybe the "domain filter" is not working and they are showing
aggregates for the whole account.

Stefano

On 28 December 2017 at 14:04, Benjamin BILLON  wrote:
> Yes, same here.
>
>
>
> IPs shown are mostly ours (although not used at all by the domain name), but
> also not ours (and potentially related to the given domain name, but I can't
> verify that)
>
>
>
> This seems to be retroactive, as even data of beginning of September display
> this behavior.
>
>
>
> From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Vaibhav
> Sent: Thursday, 28 December, 2017 12:23
> To: mailop@mailop.org
> Subject: [mailop] Issue with Gmail Postmaster
>
>
>
> Hey,
>
> Since past few days we observed that Gmail postmaster showing random IP's in
> IP reputation where same IP's is not used to sent out emails.
>
> Gmail Postmaster showing random large no. of IP in IP reputation. Does
> anyone observed that the same ?
>
> --Vaibhav
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop