Re: [mailop] DKIM by the third party

[Byung-Hee HWANG via mailop]

Dear Brandon,

Brandon Long via mailop  writes:

> Generally speaking,
> adding a dkim signature to your message adds a "source" anchor,
> something that ties a message to other messages.

INDEED, i love this statement so much!

Thanks ^^^

Sincerely, Linux fan Byung-Hee

-- 
^고맙습니다 _布德天下_ 감사합니다_^))//
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Yahoo FBL per IP Range?

[Benoît Panizzon via mailop]

Hi List

I subscribed to the Yahoo FBL on after we got some 'low volume' phished
account abused for spam and staying under our radar, targetting yahoo
recipients which now tempfails our smtp outbound ip range for 'user
complaints'.

https://io.help.yahoo.com/contact/index?page=contactform&locale=en_US&token=Zh%2FBBVqXzLHlIbokbUqVWTUbuuQeXGkGnZzhKR2JQ4O6mMQdy9JSWdtWFXvjthcYCRj9bUIFfycOfG%2B4GOHPHoOGa8HwDO2%2B0kYRtTcdR8Nja5P9HWkKh3VWfS3pyu4UdjhvwG%2BBCvnYFl5dToDK%2Fw%3D%3D&selectedChannel=email-icon

I added our ISP email service email domains. But we also host
business customer domains on that email platform, which I can not all
add.

Does anyone know, if it is possible, to register a IP Range for YFBL?

-- 
Mit freundlichen Grüssen

-Benoît Panizzon- @ HomeOffice und normal erreichbar
-- 
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Is there anyone working at Invaluement?

[Cyril - ImprovMX via mailop]

Hi everyone, sorry to bother you with such requests but I'm having a hard
time reaching out to Invaluement (https://www.invaluement.com/)

Our IPs got listed there and I'm trying to open a line of communication to
better understand what happened, in order to fix it before requesting for
delisting.

If someone on this list is working at Invaluement and can reach out to me,
that would be fantastic.

Thank you and have a nice weekend :)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Odd delay at Gmail ?

[Cyril - ImprovMX via mailop]

Hi Brandon,

Nice to meet you and thank you for answering my email.
I managed to get the eml from that user if you are interested in checking
the headers and seeing if you notice any odd behavior.

What I remain curious to know is why the Date in the Received header had
its timezone changed, but the hour was not modified accordingly to the
timezone, this is really surprising.

Best regards,
Cyril

Le ven. 22 avr. 2022 à 02:54, Brandon Long  a écrit :

> While every attempt is made to deliver mail as quickly as possible, any
> sufficiently large distributed system will occasionally have issues.
>
> We monitor the delivery latency within our systems, and act when they go
> bad.
>
> At times, there have been deliberate choices made to the design which
> allowed for extended queuing when we had datacenter outages, instead of
> insuring writes hit multiple datacenters... for example.
>
> It's also possible for individual mailboxes to be overloaded, due to the
> store & forward nature of email, it's not always possible to push back at
> smtp time, and so internal queuing occurs.
>
> Historically, it was also possible for individual mailboxes to have issues
> that could require fixing... there's still some issues due to locking of
> the entire mailbox under some scenarios, though it seems unlikely to result
> in an 8h delay.
>
> Every once in a while there's also a message-of-death or other issue,
> where something about an individual message makes our system unhappy or
> causes extensive cpu usage.
>
> And that's without adding in additional complexities that some companies
> have for their email routing, which can add a very large number of hops or
> even administrative quarantine.
>
> All of this would be visible in the Received headers of the message...
> though only the successful attempts, not the failed ones that resulted in
> retries, we considered at one point how we could add that information as
> well, but that never went anywhere.  For workspace customers, there is the
> email log search which allows you to see where a message is and retry
> attempts.  At one point I started a proposal for something simpler for
> individual mailboxes, but it got complicated quickly and didn't make the
> prioritization cutoff.
>
> Folks definitely tend to think of email communications now being as fast
> as instant messaging, and they dislike when there are delays and no
> indication of such... the fact that we'll retry a message internally for up
> to 3-5d is
> completely out of touch with what user expectations are... but bounces are
> also terrible.  Outside of making sure that a high percentile of messages
> are delivered in reasonable times, I'm not sure anyone has come up with
> a better solution.
>
> 8h would be a fairly large statistical outlier, that's for sure.
>
> Brandon
>
> On Wed, Apr 20, 2022 at 3:57 AM Cyril - ImprovMX via mailop <
> mailop@mailop.org> wrote:
>
>> Hi everyone !
>>
>> I'm reaching out in the hope to find someone in the same situation, and
>> that I can receive some input on why this happened.
>>
>> We forward a lot of emails including to Gmail, and a user reached out to
>> us because their email arrived in their inbox with a delay of 8 hours!
>>
>> That user was able to send us the .eml, so I was able to peak at the
>> headers. What I noticed is that the Date present in the email was in UTC
>> all the way up to us, but when it left our server and landed at Gmail, it
>> changed, but ... oddly.
>>
>> The "Date" header was "Thu, 14 Apr 2022 18:29:43 +" and during the
>> processing in the sender, and in our servers, it remained the same with a
>> few seconds changing, but that's all.
>>
>> We forwarded it to "gmail-smtp-in.l.google.com", and the next date
>> present (in the "Received" header) became "Thu, 14 Apr 2022 19:24:28 -0700
>> (PDT)"
>>
>> I don't mind the timezone changing, but the hour only changed for one
>> hour, while the timezone changed by an offset of 7 hours! The two changes
>> resulted in a difference of 8 hours, which is exactly when the user saw his
>> email in his inbox.
>>
>> What happened here ?
>>
>> Our logs clearly show that we forwarded the email in under 2 seconds and
>> we didn't mess with the dates (or anything, for that matter).
>>
>> Does anyone here experience this before? Do you have any explanations
>> about what happened?
>>
>> I'd love to reach out to Gmail to ask them about this, but, well, it's
>> Gmail.
>>
>> Thank you for your help!
>>
>> Best,
>> Cyril
>> ___
>> mailop mailing list
>> mailop@mailop.org
>> https://list.mailop.org/listinfo/mailop
>>
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Yahoo FBL per IP Range?

[Florian Vierke via mailop]

Hi Benoit,

That's pretty much on top of my wishlist for Christmas as well, but so far 
there's no other option for adding domains to the Yahoo FBL.

Regards,


Florian Vierke | Senior Manager, Deliverability Services
t: +49 89 12009713
e: florian.vie...@mapp.com

-Original Message-
From: mailop  On Behalf Of Benoît Panizzon via mailop
Sent: Freitag, 22. April 2022 11:52
To: mailop@mailop.org
Subject: [mailop] Yahoo FBL per IP Range?

This email has reached Mapp via an external source


Hi List

I subscribed to the Yahoo FBL on after we got some 'low volume' phished account 
abused for spam and staying under our radar, targetting yahoo recipients which 
now tempfails our smtp outbound ip range for 'user complaints'.

https://io.help.yahoo.com/contact/index?page=contactform&locale=en_US&token=Zh%2FBBVqXzLHlIbokbUqVWTUbuuQeXGkGnZzhKR2JQ4O6mMQdy9JSWdtWFXvjthcYCRj9bUIFfycOfG%2B4GOHPHoOGa8HwDO2%2B0kYRtTcdR8Nja5P9HWkKh3VWfS3pyu4UdjhvwG%2BBCvnYFl5dToDK%2Fw%3D%3D&selectedChannel=email-icon

I added our ISP email service email domains. But we also host business customer 
domains on that email platform, which I can not all add.

Does anyone know, if it is possible, to register a IP Range for YFBL?

--
Mit freundlichen Grüssen

-Benoît Panizzon- @ HomeOffice und normal erreichbar
--
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
Mapp Digital Germany GmbH with registered offices at Dachauer, Str. 63, 80335 
München.
Registered with the District Court München HRB 226181
Managing Directors: Frasier, Christopher & Warren, Steve
This e-mail is from Mapp Digital and its international legal entities and may 
contain information that is confidential or proprietary.
If you are not the intended recipient, do not read, copy or distribute the 
e-mail or any attachments. Instead, please notify the sender and delete the 
e-mail and any attachments.
Please consider the environment before printing. Thank you.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Is there anyone working at Invaluement?

[Rob McEwen via mailop]

I will answer this off list today. At invaluement, for the past 2 weeks, we've 
been in the middle of the largest hardware upgrade we've done in over 5 years, 
so we're backed up on requests like this one. We haven't even processed new 
trial requests during this crazy time. I have about 5 others requests like this 
that I've been trying to get to for the past several days. (as I understood it, 
the question was about past listings, not an active one)Sorry for the noise 
this caused!Rob McEwen, invaluementSent from my Verizon, Samsung Galaxy 
smartphoneRob McEwen, invaluement478-475-9032Sent from my Verizon, Samsung 
Galaxy smartphone
 Original message From: Cyril - ImprovMX via mailop 
 Date: 4/22/22  6:21 AM  (GMT-05:00) To: Cyril - ImprovMX 
 Subject: [mailop] Is there anyone working at Invaluement? 
Hi everyone, sorry to bother you with such requests but I'm having a hard time 
reaching out to Invaluement (https://www.invaluement.com/)Our IPs got listed 
there and I'm trying to open a line of communication to better understand what 
happened, in order to fix it before requesting for delisting.If someone on this 
list is working at Invaluement and can reach out to me, that would be 
fantastic.Thank you and have a nice weekend :)
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] BT UK: Community Mailer: Invalid Sender Address

[Benoît Panizzon via mailop]

Hi

Trying via this list as I had no success, with BT Customer Service or
via BT Switzerland.

Hopefully a BT mail admin is reading this, or somebody is able to
forward to the right person.

For certain technical telephony issues regarding international
interconnection, BT Customer Service requires the telephone operator
wanting to reporting the issue to register itself on the Community
Support site and open a case there.

But registration never is successful, because the email containing
the validation code, does not make it back. It is sent from a
domain that has no Address or MX records. That problem persists since
at least two months.

Apr 22 13:58:52 idefix postfix/smtpd[33036]: NOQUEUE: reject: RCPT from
outbound-dkim.eu.khoros-mail.com[34.255.61.190]: 450 4.1.8
: Sender address rejected: Domain not
found; from= to=<***@imp.ch>
proto=ESMTP helo=

$ host -t any community-mail.bt.com
community-mail.bt.com descriptive text "v=spf1 ip4:46.19.168.0/22
include:eu.khoros-mail.com -all"

Yes, that is the only record. No A no  no MX no CNAME.

-- 
Mit freundlichen Grüssen

-Benoît Panizzon- @ HomeOffice und normal erreichbar
-- 
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Yahoo FBL per IP Range?

[Marcel Becker via mailop]

On Fri, Apr 22, 2022 at 3:10 AM Benoît Panizzon via mailop <
mailop@mailop.org> wrote:

>
> I added our ISP email service email domains. But we also host
> business customer domains on that email platform, which I can not all
> add.
>

It might be a good idea to sign those emails leaving your platform with
your DKIM key.
That also makes it easier to get reports from us.

- Marcel
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Yahoo FBL per IP Range?

[Scott Mutter via mailop]

Been preaching about this for years.  Have yet to get anybody of value's
attention.

If you're going to block mail servers by IP address (which, to be clear, I
don't have a problem with providers doing this - and Yahoo does this along
with countless other mail services), then you need to have a feedback loop
that is IP based.

DomainKeys based feedback loops are worthless if you're an administrator on
a server that sends out mail from many, many different domains.

On Fri, Apr 22, 2022 at 7:00 AM Florian Vierke via mailop 
wrote:

> Hi Benoit,
>
> That's pretty much on top of my wishlist for Christmas as well, but so far
> there's no other option for adding domains to the Yahoo FBL.
>
> Regards,
>
>
> Florian Vierke | Senior Manager, Deliverability Services
> t: +49 89 12009713
> e: florian.vie...@mapp.com
>
> -Original Message-
> From: mailop  On Behalf Of Benoît Panizzon via
> mailop
> Sent: Freitag, 22. April 2022 11:52
> To: mailop@mailop.org
> Subject: [mailop] Yahoo FBL per IP Range?
>
> This email has reached Mapp via an external source
>
>
> Hi List
>
> I subscribed to the Yahoo FBL on after we got some 'low volume' phished
> account abused for spam and staying under our radar, targetting yahoo
> recipients which now tempfails our smtp outbound ip range for 'user
> complaints'.
>
>
> https://io.help.yahoo.com/contact/index?page=contactform&locale=en_US&token=Zh%2FBBVqXzLHlIbokbUqVWTUbuuQeXGkGnZzhKR2JQ4O6mMQdy9JSWdtWFXvjthcYCRj9bUIFfycOfG%2B4GOHPHoOGa8HwDO2%2B0kYRtTcdR8Nja5P9HWkKh3VWfS3pyu4UdjhvwG%2BBCvnYFl5dToDK%2Fw%3D%3D&selectedChannel=email-icon
>
> I added our ISP email service email domains. But we also host business
> customer domains on that email platform, which I can not all add.
>
> Does anyone know, if it is possible, to register a IP Range for YFBL?
>
> --
> Mit freundlichen Grüssen
>
> -Benoît Panizzon- @ HomeOffice und normal erreichbar
> --
> I m p r o W a r e   A G-Leiter Commerce Kunden
> __
>
> Zurlindenstrasse 29 Tel  +41 61 826 93 00
> CH-4133 PrattelnFax  +41 61 826 93 01
> Schweiz Web  http://www.imp.ch
> __
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
> Mapp Digital Germany GmbH with registered offices at Dachauer, Str. 63,
> 80335 München.
> Registered with the District Court München HRB 226181
> Managing Directors: Frasier, Christopher & Warren, Steve
> This e-mail is from Mapp Digital and its international legal entities and
> may contain information that is confidential or proprietary.
> If you are not the intended recipient, do not read, copy or distribute the
> e-mail or any attachments. Instead, please notify the sender and delete the
> e-mail and any attachments.
> Please consider the environment before printing. Thank you.
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: Yahoo FBL per IP Range?

[Marcel Becker via mailop]

On Fri, Apr 22, 2022 at 8:17 AM Scott Mutter via mailop 
wrote:

Been preaching about this for years.  Have yet to get anybody of value's
> attention.
>

I might not be of value, but I did respond to this the last time you
brought this up and shared our reasoning and perspective.

- Marcel
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Luis E . Muñoz via mailop]

On 21 Apr 2022, at 11:45, Anne Mitchell via mailop wrote:

Until Google manages to shut down outfits like MailShake and 
Woodpecker and Gmass, instead of turning a blind eye to it, Google 
will never get a handle on the abuse that goes through the Gmail API, 
in fact it feels as if they are tacitly approving it. (I suppose "shut 
down" s/b "care about". I know that my inquiries about it, and offers 
to assist, have fallen on unresponsive ears.)


The idea behind Mailshake is not bad in itself. Many CRMs also use their 
customer's mail servers. There are some things that these outfits should 
do better though:


* Verify with the domain operator that they (the ESP, via the user that 
signed up for the service) are indeed authorized to use the ESP's 
services. I've found a number of instances where an end user with an 
email account on a given domain, signed up to a certain CRM using this 
MO and started to email "prospects" from their (ahem) "lead database". 
Hilarity tends to ensue shortly after.
* Do a (much!) better job at vetting customers, including real rate 
limiting.
* Take ownership of the responsibility to _stop_ mail to whomever 
unsubscribed/complained/bounced from their mailings. And then, keep 
track of ratios and take their clients to task when thresholds are 
exceeded.


After rereading the above, I realize how delusional it sounds :-(

Happy Friday.

-lem
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] $GOOG

[Anne Mitchell via mailop]

> On Apr 22, 2022, at 11:05 AM, Luis E. Muñoz via mailop  
> wrote:
> 
> On 21 Apr 2022, at 11:45, Anne Mitchell via mailop wrote:
> 
>> Until Google manages to shut down outfits like MailShake and Woodpecker and 
>> Gmass, instead of turning a blind eye to it, Google will never get a handle 
>> on the abuse that goes through the Gmail API, in fact it feels as if they 
>> are tacitly approving it. (I suppose "shut down" s/b "care about". I know 
>> that my inquiries about it, and offers to assist, have fallen on 
>> unresponsive ears.)
> 
> The idea behind Mailshake is not bad in itself. Many CRMs also use their 
> customer's mail servers. There are some things that these outfits should do 
> better though:
> 
>   • Verify with the domain operator that they (the ESP, via the user that 
> signed up for the service) are indeed authorized to use the ESP's services. 
> I've found a number of instances where an end user with an email account on a 
> given domain, signed up to a certain CRM using this MO and started to email 
> "prospects" from their (ahem) "lead database". Hilarity tends to ensue 
> shortly after.
>   • Do a (much!) better job at vetting customers, including real rate 
> limiting.
>   • Take ownership of the responsibility to stop mail to whomever 
> unsubscribed/complained/bounced from their mailings. And then, keep track of 
> ratios and take their clients to task when thresholds are exceeded.

Well, yes, except basically they were either created to, or now do and don't 
care that they, enable people to do "cold email" by scraping email addresses, 
adding them to a list, and then sending them through the spammer's Gmail 
account so that it *looks* one to one, thereby having a bunch of 
spammer-friendly benefits including a) making it look one-to-one, and b) 
violating Federal law about an unsub link but cloaking it in it looking 
one-to-one (see "a)"). 

Woodpecker, at least, is somewhat up front about the fact that what they are 
doing is enabling their senders to violate Google's policies:

"If you exceed the sending limits (eg. 100 emails for free Gmail accounts when 
using automated tools, like Woodpecker) or send emails containing spam words 
your email provider will send us a server notification that your mailbox was 
suspended (usually for 24 hours). In such a case, Woodpecker will show an error 
on the campaign list." (https://woodpecker.co/help/how-woodpecker-sends-emails/)

So...

> After rereading the above, I realize how delusional it sounds :-(

I dunno about delusional, but much more willing to give the benefit of the 
doubt than am I.

Anne

--
Anne P. Mitchell, Attorney at Law
CEO ISIPP SuretyMail
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Author: The Email Deliverability Handbook
Board of Directors, Denver Internet Exchange
Dean Emeritus, Cyberlaw & Cybersecurity, Lincoln Law School
Prof. Emeritus, Lincoln Law School
Chair Emeritus, Asilomar Microcomputer Workshop
Counsel Emeritus: Mail Abuse Prevention System (MAPS) (now the anti-spam arm of 
TrendMicro)


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

Re: [mailop] [E] $GOOG

[Robert L Mathews via mailop]

On 4/22/22 11:00 AM, Anne Mitchell via mailop wrote:

Woodpecker, at least, is somewhat up front about the fact that what they are 
doing is enabling their senders to violate Google's policies:


A lot of these outfits aren't even trying to hide it any more, which is 
unfortunate because it risks becoming normalized.


One I saw recently was , just flat out offering 
LinkedIn scraping . I complained to 
their hosting provider Namecheap, since it clearly violates their AUP, 
but no response.


--
Robert L Mathews
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Is there anyone working at Invaluement?

[Cyril - ImprovMX via mailop]

Awesome, thank you very much for that! I wasn't aware of your massive
upgrade but can understand the delay on answering requests, no worries here!

I got your email off-list, I'll reply there asap.

Thanks!

Le ven. 22 avr. 2022 à 14:13, Rob McEwen via mailop  a
écrit :

> I will answer this off list today. At invaluement, for the past 2 weeks,
> we've been in the middle of the largest hardware upgrade we've done in over
> 5 years, so we're backed up on requests like this one. We haven't even
> processed new trial requests during this crazy time. I have about 5 others
> requests like this that I've been trying to get to for the past several
> days. (as I understood it, the question was about past listings, not an
> active one)
>
> Sorry for the noise this caused!
>
> Rob McEwen, invaluement
>
> Sent from my Verizon, Samsung Galaxy smartphone
>
>
> Rob McEwen, invaluement
> 478-475-9032
>
> Sent from my Verizon, Samsung Galaxy smartphone
>
>
>  Original message 
> From: Cyril - ImprovMX via mailop 
> Date: 4/22/22 6:21 AM (GMT-05:00)
> To: Cyril - ImprovMX 
> Subject: [mailop] Is there anyone working at Invaluement?
>
> Hi everyone, sorry to bother you with such requests but I'm having a hard
> time reaching out to Invaluement (https://www.invaluement.com/)
>
> Our IPs got listed there and I'm trying to open a line of communication to
> better understand what happened, in order to fix it before requesting for
> delisting.
>
> If someone on this list is working at Invaluement and can reach out to me,
> that would be fantastic.
>
> Thank you and have a nice weekend :)
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Increase in virus activity this week @ MXroute (perhaps others?)

[Cyril - ImprovMX via mailop]

Hi Jarland,

that was very interesting, thank you for sharing these details.

I'm curious to know how you caught this in the first place. It would be
interesting to know some technics on how to catch bad behaviors before they
get out of hand and many of us here might be interested in the how-tos and
might also learn a lot from this (me first).

thank you in advance :)

Best,
Cyril

Le ven. 22 avr. 2022 à 00:57, Jarland Donnell via mailop 
a écrit :

> Hey friends,
>
> This week at MXroute we saw an increase in compromised email accounts.
> Apologies if you saw virus spam coming from our network. Typically,
> these events are caught instantly. In cases that use new patterns and
> techniques, under 1 hour. This time, it went on intermittently for about
> half a day on 4/20 (I wish it was for THAT reason), and it happened a
> few times in the days prior. What we found was that every one of these
> outbound emails contained this virus:
>
> https://www.virustotal.com/gui/file/707d507f138a450fb4c7b5c906f280259f23f5aac808b8dfcd23b66d0d679441/detection
>
> It's not difficult to assume that the users received the same virus
> beforehand, whether by email or otherwise. The virus appears to use each
> infected computer as part of a botnet, and each computer is involved in
> authenticating over SMTP and sending out copies of the virus. The only
> thing I never saw was our infected users connecting to our servers to
> send the spam, it was always other residential IPs in various locations.
> The emails themselves are difficult to nail down into patterns. Subjects
> ranged from "Firstname Lastname" (name of recipient perhaps?) to spoofed
> PayPal receipts. The emails mostly contained HTML and often some links,
> couldn't find a case of either being the same twice. The To/From headers
> did use a consistent spoofing trend and although the actual content of
> them rarely if ever repeated, the style is easy to grab on to:
>
> Example:
>  From: "serv...@paypal.com" 
> To: "2...@mail01.netgate.com.uy" <2...@mail01.netgate.com.uy>
>
> Frankly, the "To" header alone may be a consistent way to just shut
> these down until the patterns change. However, ensuring that the virus
> signature is present on inbound and outbound scanners is more likely to
> be effective for a longer period of time, I suspect.
>
> Finally, the last part of the trend which is noteworthy, all of the
> email accounts sent out a "test" email first. Unfortunately, it was
> rarely to the same recipient. Rarely, but not never. Two sample test
> email logs:
>
> 2022-04-20 12:53:58 1nh9qH-0008OE-RW <= winfield@{our customer's
> domain}.com H=host-79-10-109-221.business.telecomitalia.it (localhost)
> [79.10.109.221] P=esmtpsa X=TLS1.2:ECDHE-ECDSA-AES128-GCM-SHA256:128
> CV=no A=login:winfield@{our customer's domain}.com S=735 T="ZYaeD, X "
> from  for
> toewebvastsatw...@gmx.com
>
> 2022-04-20 12:53:40 1nh9q0-00HECV-Al <= register@{our customer's
> domain}.org H=mail.dfclark.co.uk (localhost) [149.255.169.82] P=esmtpsa
> X=TLS1.3:TLS_AES_256_GCM_SHA384:256 CV=no A=login:register@{our
> customer's domain}.org S=691 T="wFd2, MkRWa2 A" from  customer's domain}.org> for toewebvastsatw...@gmx.com
>
> And for kicks, a few sample email subjects: https://clbin.com/dGT1y
> (sorted by count of repeat subjects from one compromised account)
>
> I sincerely hope that this helps someone else in the never-ending effort
> to keep IPs clean.
>
> Sincerely,
> Jarland Donnell
> MXroute Administrator
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] DKIM by the third party

[Ángel via mailop]

On 2022-04-21 at 10:04 +0800, Henrik S via mailop wrote:
> Hello
> 
> My mail is sent by the third party smtp server, and the dkim
> signature 
> is made for the third party domain (for this case, it's pobox.com).
> 
> does this DKIM have helps to the authorization of my outgoing
> messages?
> 
> Thanks

I believe the answer for what you are actually trying to ask is NO.

In the usual context of email communication, if I receive an email
 From: Henrik S 

what I would want to know if whether it really comes from 
tomatoservers.com. As such, a signature by pobox.com would have no
value for that.

That is the stance by DMARC, which expects that email with a From: of 
tomatoservers.com to be signed by a DKIM signature of tomatoservers.com
 or to have a SPF for that (which you have set).


Technically, DKIM (RFC 6376) doesn't preclude for signing email not
from unrelated parties, and those would typically be ignored by other
systems.
Or used for unrelated reasons to actual mail delivery, such as giving
access to GPT, as Laura mentions.

However, *some* systems do give more weight when signed by third-party
keys that are "good".
If -historically- most email signed by pobox.com is not spam, your 
tomatoservers.com signed by pobox.com is probalby leaning as well to
not being spam. This may be taken into account when weighting it.
Whereas if mail signed by pobox.com has a 50% chance of being spam,
that signature wouldn't help.

In summary, having a signature from pobox.com in your tomatoservers.com
 won't "authorize" your outgoing mail as really coming from 
tomatoservers.com.

However, with some server that pobox.com signature might have some
value (positive or negative) and so not being completely zero.


Years ago, dkim-reputation.org provided a database of good/bad
senders[1]. I don't know if there are other similar reputation services
now (big players obviously have their own data for that).

I would be interested on what are other (smaller) parties doing (if
any) to measure the "goodness" of valid DKIM signatures.
Also, the signature could simply treat the DKIM signature as a link
with the signer domain (in this case pobox.com). Or it could also take
into account the specific signature chosen (either the selector or the
key), so that different email flows could bear different signatures and
receive different weight.
However, the later case would obstruct key rotation, discouraging the
rotation of a DKIM key perceived to have an high value.


Regards


1- https://web.archive.org/web/20170712210708/http://www.dkim-reputation.org/

PS: Interestingly, I was precisely a similar discussion about DKIM
reputation just a few days ago.


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

[mailop] MTA-STS Policy File Syntax Question

[Faisal Misle via mailop]

Hello all,

Got a quick question regarding the syntax of an MTA-STS policy file.

Example:

version: STSv1
mode: testing
mx: mx.example.com
max_age: 86400

vs.

version: STSv1
mode: testing
mx: mx.example.com.
max_age: 86400

Note the trailing dot on the second policy. Is that a valid MX for the 
policies of the file? I could not find anything about it on RFC 8461 and 
most validators were flagging it as an invalid MX.


Looking forward to hearing your thoughts!

-Faisal
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] FYI - Google/Gmail hard enforcing SPF presence

[Faisal Misle via mailop]

Does anyone have the bounce message they're sending back handy?

On 4/19/22 6:36 PM, Jarland Donnell via mailop wrote:
To add +1 experience to this, I've been seeing it intermittently. Some 
of my customers who lack SPF absolutely cannot deliver mail to Gmail, 
100% rejection due to lack of authentication. Others, not so much. I 
can't pretend to know what the criteria is for falling into the former, 
but it hasn't been a large number of domains we've noticed it on.


On 2022-04-19 02:20, Andre van Eyssen via mailop wrote:

Hi all,

A week or so ago I was dealing with some domains that were nearly 100%
bouncing on delivery to gmail. It turns out that the domain owners had
made registrar/DNS hosting changes and while they managed to create
the MX records correctly, they left out the SPF.

A little testing shows that gmail appears to be rejecting all mail
from domains with no SPF record. Having them create the SPF record
returned their domains to deliverability in about an hour.

Just a heads-up!

Andre.

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

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

Re: [mailop] DKIM by the third party

[John Levine via mailop]

It appears that � ngel via mailop  said:
>In the usual context of email communication, if I receive an email
> From: Henrik S 
>
>what I would want to know if whether it really comes from 
>tomatoservers.com. As such, a signature by pobox.com would have no
>value for that.

Keep in mind that knowing whether it's signed by tomatoservers.com
tells you nothing by itself about whether it's spam.

For that you need an identifier with some reputation (good or bad) and DKIM
signatures from pobox.com and tomatoservers.com could both be useful for that.
Pobox is likely to be more useful since the sign more mail and so have a more
reliable reputation.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] MTA-STS Policy File Syntax Question

[Ángel via mailop]

On 2022-04-22 at 17:30 -0500, Faisal Misle via mailop wrote:
> Note the trailing dot on the second policy. Is that a valid MX for the 
> policies of the file? I could not find anything about it on RFC 8461 and 
> most validators were flagging it as an invalid MX.
> 
> Looking forward to hearing your thoughts!
> 
> -Faisal

That trailing . (the root zone) appears on dns and in the ouput of e.g.
host(1), but I don't think it is valid in the context of a STS policy
file (even though I often leave that triling . when writing local STS
overrides)

RFC 8461 don't mention trailing dots in the text, nor they appear on
the samples. This is a good indication it isn't expected.

And for the formal rules, rfc8461 defers to rfc6125, which basically
say "the text must be the same case-insensitive"

> If the DNS domain name portion of a reference identifier is a
>"traditional domain name", then matching of the reference identifier
>against the presented identifier is performed by comparing the set of
>domain name labels using a case-insensitive ASCII comparison, as
>clarified by [DNS-CASE] (e.g., "WWW.Example.Com" would be lower-cased
>to "www.example.com" for comparison purposes).  Each label MUST match
>in order for the names to be considered to match

(*) skipping over the mentions of wildcards for clarity


Thus my conclusion is that the mx entries MUST NOT have such trailing
dots.
Furthermore, the fact that validators reject them is a sign that
implementations are likely to reject them as well, which would lead to
email not being delivered (since no mx would match)

Nonetheless, per Postel's Law, a client MAY wish to ignore such
trailing   dots and I think it would be fine.


Best regards


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