Re: [mailop] ebay postmaster contact

2024-01-27 Thread Randolf Richardson, Postmaster via mailop
Have you inspected the SMTP headers and grepped mail server logs?

> Hello!
> 
> Does anybody of ebay reads here?
> 
> At work we receive mails from ebay (SPF valid) to an address that isn't
> assigned to an account and can't be registered by the ebay user because
> he can't access the inbox, it is root@our.domain.
> 
> I already called their customer service and they said the email address
> isn't assigned to any ebay account.
> 
> We receive invoices and private messages for the ebay user here.
> 
> rcpt to is root@ on our MX, so it is not a forward/alias in our system
> 
> Is there any way to contact them so they can figure out the source of
> those mails?
> 
> -- 
> kind regards
> Marco
> 
> Spam und Werbung bitte an ichschickerekl...@cartoonies.org
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop


-- 
Postmaster - postmas...@inter-corporate.com
Randolf Richardson, CNA - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
https://www.inter-corporate.com/


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


Re: [mailop] Extortion spam from OVH-hosted *.sbs domains

2024-01-27 Thread Hans-Martin Mosner via mailop

Am 26.01.24 um 09:42 schrieb Simon Bressier via mailop:

Hi all,

FYI Hans-Martin, I reached out to ovh team yesterday night to push your message, seems your abuse report has been 
processed by the proper team. No idea if they answered you, but at least, they have handled the report, and probably 
done the appropriate actions.


Actions maybe, appropriate probably not.

Today the spammers use .sbs domains on OVH IPs again:

mx.h.orku.sbs 51.68.81.175
mx.j.eown.sbs 51.89.230.64
mx.a.mykf.sbs 146.59.116.127

I can't see the content, as we refuse to accept anything from *.sbs at the 
moment, for good reasons.

Cheers,
Hans-Martin
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] DKIM signed with parent domain

2024-01-27 Thread Jaroslaw Rafa via mailop
Dnia 26.01.2024 o godz. 22:06:44 Gellner, Oliver via mailop pisze:
> Independent of this I wouldn’t use r...@hostname.example.org as a sender
> address to external recipients. This doesn’t look professional, makes
> replying to those emails impossible and in case hostname.example.org
> doesn’t have a public IP address it might also increase the risk that
> those messages are treated as spam or rejected, because they are coming
> from an unresolvable domain.

While you are obviously right about the unresolvable domain case, but if
hostname.example.org is resolvable (and if that host is a MX for
example.org, it will be), what makes you think that replying to an email
from r...@hostname.example.org is impossible?

In the past I've done it dozens of times and it always worked. Unless of
course root account was configured to reject mail, but this is not a common
configuration.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] [E] Re: Spamfolder mini rant (Was: Contact Google Postmaster)

2024-01-27 Thread Marcel Becker via mailop
On Sat, Jan 27, 2024 at 13:33 Thomas Walter via mailop 
wrote:

>
> Well, there could be if providers would stop delivering what they think
> is spam into spamfolders and reject it instead.


That’s actually what they already do in 99% of all spam cases. Rejecting
known bad email at the gate is the goal.

To me it just doesn't make a lot of sense to basically have two inboxes
> to check - the regular one and the spamfolder.


I think we all agree.

Yes, I know, spamfolders are used for training


It mainly exists for legal reasons.

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


Re: [mailop] DKIM signed with parent domain

2024-01-27 Thread Byung-Hee HWANG via mailop
Hellow Slavko,

On Sat, 2024-01-27 at 08:10 +, Slavko via mailop wrote:
> Dňa 27. januára 2024 3:59:54 UTC používateľ Byung-Hee HWANG via
> mailop  napísal:
> 
> > 
> > Google Gmail accept such email: (source from soyeo...@gmail.com)
> > https://gitlab.com/soyeomul/Gnus/-/raw/d73303d3f304a275bb6f129c0d4934ce30680629/DKIM/gmail-forwarding-header-20240126.txt
> 
> AFAIK:
> 
> + standalone DKIM has no dependency on any email header
> + DMARC has option how strictly verify DKIM alignment
> 
> Thus, make sure proper settings and it should be ok (RFC compliant).
> 
> If some site will not accept that, it is its bug. To be sure, one can
> setup separate DMARC record for subdomain with separate
> rua= target defined and watch (inspect) reports for some time.
> 

These days, i'm reading RFC 8617 from time to time. Thanks for your
kind advice!


Sincerely, Byung-Hee

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


Re: [mailop] DKIM signed with parent domain

2024-01-27 Thread Gellner, Oliver via mailop

> On 27.01.2024 at 03:23 Grant Taylor via mailop wrote:
> On 1/26/24 16:06, Gellner, Oliver via mailop wrote:
>> Independent of this I wouldn’t use r...@hostname.example.org as a sender 
>> address to external recipients. This doesn’t look professional,
>
> I'll agree that sending from root@ is not best practice.  But I 
> don't know if it's unprofessional per se.

If I as a customer or business partner would receive emails which are coming 
from apa...@webserver1.company.tld then I‘d be under the impression that this 
company lost control of their infrastructure. But maybe that’s just me.

>> makes replying to those emails impossible
>
> I question the veracity of that.
>
> Including a Reply-To: and / or an MX for  to a reachable mail 
> server that is a smart host that knows how to deliver email to a host that's 
> not directly reachable seems viable to me.

I should have been more precise: Technically it’s of course possible to send 
emails to @hostfqdn, there is nothing special about this email address after 
all. However the original question in this thread was that it’s too much work 
to add and maintain TXT entries for all host FQDNs. I conclude from this that 
the same applies to adding and maintaining MX entries for all host FQDNs, let 
alone modify all emails to include Reply-To headers.

>> and in case hostname.example.org doesn’t have a public IP address it might 
>> also increase the risk that those messages are treated as spam or rejected, 
>> because they are coming from an unresolvable domain.
>
> I question the veracity of anything that balks at a valid MX via smart host 
> for a  that is in and of itself unreachble.
>
> After all, what is the effective difference in a host that's in a private 
> network using a smart host for outbound and inbound mail and a host usually 
> fully reachable / on the Internet that happens to be offline do to an 
> extended power outage caused by a winter storm?

I didn’t write that the hosts have to be reachable. Chances are that the FQDN 
of at least some of the hosts in the company network are not publicly 
resolvable, because for example they are not reachable from the internet 
anyway. That means looking up A /  / MX of hostname.example.com would yield 
NXDOMAIN. This may cause deliverability problems.

—
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Spamfolder mini rant (Was: Contact Google Postmaster)

2024-01-27 Thread Thomas Walter via mailop

Hello,

On 27.01.24 12:47, Laura Atkins via mailop wrote:
There is remediation available. What there isn’t is some imprimatur that 
ensures that every email is delivered to the inbox every time unless the 
sender considers it spam and agrees with the decision. That’s just not 
how it works.



Well, there could be if providers would stop delivering what they think 
is spam into spamfolders and reject it instead.


To me it just doesn't make a lot of sense to basically have two inboxes 
to check - the regular one and the spamfolder.


Also having to tell people to check their spamfolders every time they 
are missing an email is annoying too.


I'd rather know that my email was considered spam than trying to figure 
out why someone did not reply after a few days. At least that would give 
me a chance to use a different contact method or try to resolve the 
issue in the first place.


Yes, I know, spamfolders are used for training, but perhaps there should 
be other ways?



Regards,
Thomas Walter

--
Thomas Walter
Datenverarbeitungszentrale

FH Münster
- University of Applied Sciences -
Corrensstr. 25, Raum B 112
48149 Münster

Tel: +49 251 83 64 908
Fax: +49 251 83 64 910
www.fh-muenster.de/dvz/


smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Re: [mailop] Contact Google Postmaster

2024-01-27 Thread Laura Atkins via mailop


> On 26 Jan 2024, at 23:21, Scott Mutter via mailop  wrote:
> 
> I've had domains listed in Google Postmaster Tools since 2016.  Never gotten 
> one lick of any information from any of those except for "No data to display 
> at this time. Please come back later. Postmaster Tools requires that your 
> domain satisfies certain conditions before data is visible for this chart."
> 
> I eventually stopped adding domains because it didn't do me any good.
> 
> The 173.225.104.91 server has sent 68 emails to gmail.com  
> email addresses thus far in January 2024.  As far as I know, this block just 
> happened today.  Today was the first time it was brought to my attention that 
> messages from this server are going into the spam folder.
> 
> Again, how am I supposed to know that Google is treating this IP's reputation 
> poorly?
> 
> How am I supposed to remedy a low reputation?
> 
> 
> I set up another domain on the same 173.225.104.91 server, SPF, DKIM, and 
> DMARC all set up (and verified with https://www.learndmarc.com 
> ).  Sent a message to an @gmail.com 
>  address through this account, and it went to the spam 
> folder.
> 
> Set up the same domain on another server - 205.209.102.251 - which, 
> coincidentally is also an Interserver IP.  Again, verified that SPF, DKIM, 
> and DMARC were all set up with https://www.learndmarc.com 
> .  I sent the same test message to the same 
> @gmail.com  address.  Message came through in the INBOX 
> without incident.
> 
> What conclusions would everybody else draw?

That spam filtering is fickle and deliverability troubleshooting is about 
statistics and machine learning.

It’s near impossible to troubleshoot delivery failures at this volume. It may 
or may not be a reputation issue. It might be a link you’re using, it might be 
the domain is too new, it might be any of a dozen different things.

> It's frustrating because none of the too big to fail email service providers 
> have any way to test a sending IP or sending domain's reputation with their 
> service.  They block them or weigh them heavily without any method of 
> remediation.

There is remediation available. What there isn’t is some imprimatur that 
ensures that every email is delivered to the inbox every time unless the sender 
considers it spam and agrees with the decision. That’s just not how it works.

> It would be nice if I could check the reputation of my outbound IPs daily and 
> be proactive in remedying any issues with these major email service 
> providers, rather than have to be told by my clients that something is amiss. 
>  And then battle through a 2 week waiting period for the provider to reply 
> back or hope that someone from the provider is on MailOps and can provide any 
> insight.


You’re blaming the IP but Google filtering isn’t that determinative. 

laura 

-- 
The Delivery Expert

Laura Atkins
Word to the Wise
la...@wordtothewise.com

Delivery hints and commentary: http://wordtothewise.com/blog






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


Re: [mailop] DKIM signed with parent domain

2024-01-27 Thread Slavko via mailop
Dňa 27. januára 2024 3:59:54 UTC používateľ Byung-Hee HWANG via mailop 
 napísal:

>
>Google Gmail accept such email: (source from soyeo...@gmail.com)
>https://gitlab.com/soyeomul/Gnus/-/raw/d73303d3f304a275bb6f129c0d4934ce30680629/DKIM/gmail-forwarding-header-20240126.txt

AFAIK:

+ standalone DKIM has no dependency on any email header
+ DMARC has option how strictly verify DKIM alignment

Thus, make sure proper settings and it should be ok (RFC compliant).

If some site will not accept that, it is its bug. To be sure, one can
setup separate DMARC record for subdomain with separate
rua= target defined and watch (inspect) reports for some time.

regards


-- 
Slavko
https://www.slavino.sk/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop