Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"

[Chris via mailop]

On 2020-08-26 13:36, flo via mailop wrote:

Hi there

Have any of you had any bad experiences with Deutsche Telekom lately?
They put one of my servers on their blacklist after an IP change with
the reason that I have to provide an imprint on that machine.
Have I missed something? Is this how it is done now?
I have been running mail servers for years, both professionally and in
my private life, never had problems of this kind before.
I prefer not to put my private address unprotected on the internet.


You could make nasty remarks about them forcing you to 
self-violate GDPR just to email to their customers.


I'm sure that some privacy advocate could word that in a sufficiently 
bowel-loosening fashion that brings out the torches and pitchforks.


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

Re: [mailop] firebasestorage.googleapis.com any legitimate uses?

[Brandon Long via mailop]

Sometimes sites like those have enough info in the url that you can split
it into separate uses/customers yourself, and run different
volume/reputation checking on each separate thing, and that can be useful.

It does seem like that site has a decent amount of non-spam mail usage, but
whether that applies to your users or is enough to care instead of adding
to a blacklist is kind of up to you.

Brandon

On Thu, Aug 27, 2020 at 5:35 AM Benoit Panizzon via mailop <
mailop@mailop.org> wrote:

> Hi List
>
> In the last couple of days we face an increasing amount of phishing
> sites hosted @ firebasestorage.googleapis.com targeting our customers.
>
> They get taken down rather quickly when added to phishtank.com, but
> still they are valid for one or two days after reception, long enough
> for stup** customers to send in their credentials.
>
> *.googleapis.com is whitelisted so it won't get blacklisted by our RBL
> blacklist.
>
> Now I start to wonder, is this URI also being used in legitimate
> emails, or is it uniquely used in phishing emails and similar?
>
> I could manually add firebasestorage.googleapis.com to the blacklist
> which would have precedence over the wildcard whitelist entry.
>
> Mit freundlichen Grüssen
>
> -Benoît Panizzon-
> --
> I m p r o W a r e   A G-Leiter Commerce Kunden
> __
>
> Zurlindenstrasse 29 Tel  +41 61 826 93 00
> <+41%2061%20826%2093%2000>
> CH-4133 PrattelnFax  +41 61 826 93 01
> <+41%2061%20826%2093%2001>
> Schweiz Web  http://www.imp.ch
> __
>
> ___
> 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] Digital Ocean Broken Bot attack, just in case it's you and not me..

[Chris via mailop]

Lots of attacks coming from this block I'm only seeing non-SMTP attacks 
however.


Things like attempted SMB breakins, telnet password probing (likely 
IoT), VOIP attacks, a variety of botnets.


This could be a badly infected netblock or a dynamic segment with no 
method to prevent IP hopping.


This is one of those drop-at-the-router netblocks.

On 2020-07-07 19:45, Michael Peddemors via mailop wrote:
Very High volume SMTP Auth type attacks, but either a broken bot, or an 
attempt at Denial of Service..


Range,  192.241.227.0/24
Naming Convention: zg-0626-70.stretchoid.com

It's a 'fast talker' attack, sending EHLO before waiting for the CONNECT 
string..


Just in case anyone else is encountering this attack..

And if there is a DO guy onlist with a heart, he can pull the plug on 
those..


And if the hacker is on this list, fix your bot! It isn't going to get 
far if you are trying an AUTH attack, as a fast talker ;)


Just an annoyance..









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

Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"

[Graeme Fowler via mailop]

On 27 Aug 2020, at 16:53, Tim Bray via mailop  wrote:
> Why t-mobile want to white list, I don't know.  But you can be sure they 
> don't get random spam from random compromised home broadband or cloud servers.

...until someone registers an IP with them, then $time passes and they 
terminate service or relocate to another provider and that IP address gets 
recycled onto a different, less technically able customer who's just been given 
a free pass into Deutche Telekom's mail system.

Or, nothiswouldneverhappenwouldit, a spammer/scammer sets up a perfectly 
legitimate company with a registered office and everything, gets allowed in, 
and then changes modus operandi. Rinse, repeat.

As many parties have said, the approach taken here simply doesn't scale in so 
many ways.

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

Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"

[Tim Bray via mailop]

On 27/08/2020 10:30, G. Miliotis via mailop wrote:
Not everyone is a business with already-public information. I run my 
own server and host some domains on that. What assurances do I have 
that my personal information is protected by T-Mobile / DT after I 
send it to them? Why should I be forced to make this information 
public on a website? What's the point if I can just take it down the 
next day? 


They know your email address. :)

It's a cultural and legal German thing.  It is quite common when doing 
business to want to know exactly who or what kind of company you are 
dealing with.  And everybody has an imprint or impressum section on 
their website


They also have multiple company registries and different types of 
company.   And they like compliance.


The same kind of regulations exist in the UK, but everybody forgets 
about them.    You often see business names on websites that don't match 
their legal entity; confusions between sole trader (just a person) and a 
registered company (limited, unlimited or one of the other types).


uk regs:  https://www.bromley.gov.uk/leaflet/204102/4/675/d

"Companies must disclose the following particulars on their business 
letters, order forms and websites"



Why t-mobile want to white list, I don't know.  But you can be sure they 
don't get random spam from random compromised home broadband or cloud 
servers.



--
Tim Bray
Huddersfield, GB
t...@kooky.org


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

Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"

[Ángel via mailop]

On 2020-08-27 at 12:22 +0200, Jaroslaw Rafa via mailop wrote:
> This is so absurd that it's even hard to find words to describe it.
> 
> And it should be - in my opinion - a reason for everyone to block all
> e-mails FROM t-online.de in return.
> Maybe such an Internet-wide block will force them to change their
> absurd policy.

Just block them with the message: "Wrong address or misconfigured
system. Your sender address is unable to receive mail."


 From your point of view, it's exactly what's happening. And for the
poor t-online client, it doesn't make sense that he's not able to send
an email to someone just because t-online doesn't know the company
address of their recipient (not that it should be their business,
either).

Regards

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

Re: [mailop] firebasestorage.googleapis.com any legitimate uses?

[Graeme Fowler via mailop]

On 27 Aug 2020, at 13:46, micah anderson via mailop  wrote:
> Benoit Panizzon via mailop  writes:
> 
>> In the last couple of days we face an increasing amount of phishing
>> sites hosted @ firebasestorage.googleapis.com targeting our customers.
> 
> We have been hit by the same, although strangely it has not been
> happening so much recently.

At $workplace we ended up putting a SpamAssassin rule for these, and hang the 
false positives (we've had two reported). I know we're rejecting some marketing 
email (Jet2 Holidays being one example).

The sheer number of messages mentioning the firebase storage API in URLs in the 
message - whether clicky-linky, or others like embedded images has been fairly 
astonishing.

There was another cloud storage widget being used in phish that reared up this 
morning but I can't remember what it was. It seems that it's "tactic du jour".

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

Re: [mailop] firebasestorage.googleapis.com any legitimate uses?

[Suresh Ramasubramanian via mailop]

Also page.link which seems to be a firebase hosted / google owned shortener

Sample hxxps://fv01zz75.page.link/amTC redirecting to 
hxxp://dach-sovet.ru/opros?utm=2

On 27/08/20, 6:22 PM, "mailop on behalf of micah anderson via mailop" 
 wrote:


Hi,

Benoit Panizzon via mailop  writes:

> In the last couple of days we face an increasing amount of phishing
> sites hosted @ firebasestorage.googleapis.com targeting our customers.

We have been hit by the same, although strangely it has not been
happening so much recently.

> Now I start to wonder, is this URI also being used in legitimate
> emails, or is it uniquely used in phishing emails and similar?

Unfortunately, it is used by legitimate emails. We had to be careful not
to block the false positives.

We reported quite actively the compromised domains, and at one point I
thought we had a inside contact who would help with this, but radio
silence.

-- 
micah

___
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] firebasestorage.googleapis.com any legitimate uses?

[micah anderson via mailop]

Hi,

Benoit Panizzon via mailop  writes:

> In the last couple of days we face an increasing amount of phishing
> sites hosted @ firebasestorage.googleapis.com targeting our customers.

We have been hit by the same, although strangely it has not been
happening so much recently.

> Now I start to wonder, is this URI also being used in legitimate
> emails, or is it uniquely used in phishing emails and similar?

Unfortunately, it is used by legitimate emails. We had to be careful not
to block the false positives.

We reported quite actively the compromised domains, and at one point I
thought we had a inside contact who would help with this, but radio
silence.

-- 
micah

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

Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"

[Paul Smith via mailop]

On 27/08/2020 12:39, Jaroslaw Rafa via mailop wrote:

It's rather strange that you are comparing this to SPF.
1) SPF has no "default deny" policy; if a domain has no SPF record at all,
then mail is (or at least should be) accepted by default.


No, but it's possible for a receiver to have a policy to not accept mail 
from an unknown server that doesn't match the sending domain's SPF 
record (and that such a record has to exist). If you're going to have 
the sending server have to have some form of 'authorisation', then 
requiring SPF would be better than requiring an one-off ad-hoc 
authorisation method.



2) as the original poster mentioned, once you have authorized your server
with them, you can send mail *with any sender domain*. It does not compare
to SPF in any way.


I missed that. I thought they had to say 'this mail server can send from 
this domain'. If the server can send from *any* domain, then it's a 
useless policy, as well as being unscalable.



--
Paul
Paul Smith Computer Services
supp...@pscs.co.uk - 01484 855800


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

[mailop] firebasestorage.googleapis.com any legitimate uses?

[Benoit Panizzon via mailop]

Hi List

In the last couple of days we face an increasing amount of phishing
sites hosted @ firebasestorage.googleapis.com targeting our customers.

They get taken down rather quickly when added to phishtank.com, but
still they are valid for one or two days after reception, long enough
for stup** customers to send in their credentials.

*.googleapis.com is whitelisted so it won't get blacklisted by our RBL
blacklist.

Now I start to wonder, is this URI also being used in legitimate
emails, or is it uniquely used in phishing emails and similar?

I could manually add firebasestorage.googleapis.com to the blacklist
which would have precedence over the wildcard whitelist entry.

Mit freundlichen Grüssen

-Benoît Panizzon-
-- 
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://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] [EXTERNAL] Re: Deutsche Telekom rejects connections because of missing "provider identification"

[Brotman, Alex via mailop]

Alternately, cloud providers could block port 25 outbound by default, requiring 
new instances/owners to perform some action to be allowed to use port 25.  Some 
VPN and Tunnel providers do that now.  Really depends where you want to place 
the burden.

I feel like I've seen an RBL operator or two including categorizations for 
Cloud IP space to help MBPs have more information to make decisions.

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

> -Original Message-
> From: mailop  On Behalf Of Jaroslaw Rafa via
> mailop
> Sent: Thursday, August 27, 2020 6:22 AM
> To: mailop@mailop.org
> Subject: [EXTERNAL] Re: [mailop] Deutsche Telekom rejects connections
> because of missing "provider identification"
>
> Dnia 27.08.2020 o godz. 09:21:20 Felix Zielcke via mailop pisze:
> > Deutsche Telekom uses a whitelist which IPs can send mails to @t-
> > online.de accounts. They block every IP by default.
> >
> > So if you got some cloud vm with a new IP address, which never before
> > sent mail to a @t-online.de address, mails will be rejected.
> > You need to write their postmasters so it gets added to their
> > whitelist. And for this process you need to have a small web page with
> > your personal address listed if your server is run privately.
>
> This is so absurd that it's even hard to find words to describe it.
>
> And it should be - in my opinion - a reason for everyone to block all e-mails
> FROM t-online.de in return.
> Maybe such an Internet-wide block will force them to change their absurd
> policy.
> --
> 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://urldefense.com/v3/__https://chilli.nosignal.org/cgi-
> bin/mailman/listinfo/mailop__;!!CQl3mcHX2A!S23BuDfgTodTdXo2GL-
> 8xu8au4MQTZDTyeB_NmTJzyYL_53JNHhSlBO7HOAG4raq_5Nm$
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"

[Jaroslaw Rafa via mailop]

Dnia 27.08.2020 o godz. 12:06:29 Paul Smith via mailop pisze:
> >>So if you got some cloud vm with a new IP address, which never before
> >>sent mail to a @t-online.de address, mails will be rejected.
> >>You need to write their postmasters so it gets added to their
> >>whitelist. And for this process you need to have a small web page with
> >>your personal address listed if your server is run privately.
> >This is so absurd that it's even hard to find words to describe it.
> 
> It's the sort of thing that you'd think maybe someone should make a
> standardised way to authorise servers to send email from a domain.
> Maybe they could call it something fancy like 'Sender Policy
> Framework' or something?..

It's rather strange that you are comparing this to SPF.
1) SPF has no "default deny" policy; if a domain has no SPF record at all,
then mail is (or at least should be) accepted by default.
2) as the original poster mentioned, once you have authorized your server
with them, you can send mail *with any sender domain*. It does not compare
to SPF in any way.
-- 
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://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"

[Paul Smith via mailop]

On 27/08/2020 11:22, Jaroslaw Rafa via mailop wrote:



So if you got some cloud vm with a new IP address, which never before
sent mail to a @t-online.de address, mails will be rejected.
You need to write their postmasters so it gets added to their
whitelist. And for this process you need to have a small web page with
your personal address listed if your server is run privately.

This is so absurd that it's even hard to find words to describe it.


It's the sort of thing that you'd think maybe someone should make a 
standardised way to authorise servers to send email from a domain. Maybe 
they could call it something fancy like 'Sender Policy Framework' or 
something?..



--
Paul
Paul Smith Computer Services
supp...@pscs.co.uk - 01484 855800


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

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

Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"

[Jaroslaw Rafa via mailop]

Dnia 27.08.2020 o godz. 09:21:20 Felix Zielcke via mailop pisze:
> Deutsche Telekom uses a whitelist which IPs can send mails to @t-
> online.de accounts. They block every IP by default.
> 
> So if you got some cloud vm with a new IP address, which never before
> sent mail to a @t-online.de address, mails will be rejected.
> You need to write their postmasters so it gets added to their
> whitelist. And for this process you need to have a small web page with
> your personal address listed if your server is run privately.

This is so absurd that it's even hard to find words to describe it.

And it should be - in my opinion - a reason for everyone to block all
e-mails FROM t-online.de in return.
Maybe such an Internet-wide block will force them to change their absurd
policy.
-- 
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://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"

[G. Miliotis via mailop]

On 26/8/2020 20:36, flo via mailop wrote:

I prefer not to put my private address unprotected on the internet.


Well duh.

Not everyone is a business with already-public information. I run my own 
server and host some domains on that. What assurances do I have that my 
personal information is protected by T-Mobile / DT after I send it to 
them? Why should I be forced to make this information public on a 
website? What's the point if I can just take it down the next day?


When I had a whois record for my IP range with information and it was 
public, I was not happy but at least it made some sense. Now that WHOIS 
is considered a privacy leak, DT's scheme makes even less sense.


My guess is they're just throwing cheap labor at a problem instead of 
actually thinking it through. I guess an army of interns is better on 
the finances than actual spam fighting experts and scalable infrastructure.


Also, this is another walled garden and I can't believe their business 
customers (if the same method is used on them) would stay with them long.


--GM


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

Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"

[Johann Klasek via mailop]

On Thu, Aug 27, 2020 at 09:21:20AM +0200, Felix Zielcke via mailop wrote:
[..]
> Deutsche Telekom uses a whitelist which IPs can send mails to @t-
> online.de accounts. They block every IP by default.
> 
> So if you got some cloud vm with a new IP address, which never before
> sent mail to a @t-online.de address, mails will be rejected.
> You need to write their postmasters so it gets added to their
> whitelist. And for this process you need to have a small web page with
> your personal address listed if your server is run privately.

Awesome, how many personell do they engage with this process? Will such a
scheme ever scale? This looks like a method out of dispair...

Thinking of if every other recipient around the internet is going to
force sender to register this way... every postmaster group would drown
by such a task.

Johann


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

Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"

[Jörg Backschues via mailop]

Am 27.08.2020 um 08:37 schrieb Tom Ivar Helbekkmo via mailop:


T-Online (or Deutsche Telekom) require that somewhere on your domain is
your address visible. Even if you don't have a web page at all. And
just use the domain for sending mails.


If only there were some standardized mechanism for this information...
Someone should make one, I think.  We could call it "whois".  :)


My experience with Deutsche Telekom: I've created a web page like 
 with detailed information about the 
mail service. That has always been accepted in the past by T-Online.


--
Regards
Jörg

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

Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"

[Felix Zielcke via mailop]

Am Donnerstag, den 27.08.2020, 09:21 +0200 schrieb Felix Zielcke via
mailop:
> Am Donnerstag, den 27.08.2020, 09:02 +0200 schrieb Renaud Allard via
> mailop:
> > Does this mean that if you send a mail for "u...@domain.com" from
> > the 
> > server "mail.example.com" with a correct FCrDNS, it will be denied 
> > because domains don't match?
> > If yes, this is the most stupid idea ever, as this cannot work for 
> > shared mail hosting. Or maybe they have done exceptions for things
> > like 
> > o365 or gmail servers.
> 
> No.
> Deutsche Telekom uses a whitelist which IPs can send mails to @t-
> online.de accounts. They block every IP by default.
> 
> So if you got some cloud vm with a new IP address, which never before
> sent mail to a @t-online.de address, mails will be rejected.
> You need to write their postmasters so it gets added to their
> whitelist. And for this process you need to have a small web page
> with
> your personal address listed if your server is run privately.
> 
> 

To make it a bit more clear:

The domain of the PTR of your MTA sending IP counts.
Not the one in the From Header of your emails.
If you got once your sending IP whitelisted, it doestn't matter how
many domains you run on it. And if they have a web page or not.


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

Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"

[Felix Zielcke via mailop]

Am Donnerstag, den 27.08.2020, 09:02 +0200 schrieb Renaud Allard via
mailop:
> 
> On 8/27/20 8:24 AM, Felix Zielcke via mailop wrote:
> > Am Mittwoch, den 26.08.2020, 21:06 +0200 schrieb ml+mailop--- via
> > mailop:
> > > > But it was enough to have the imprint visible for them just for
> > > > the
> > > 
> > > Sorry for a stupid question: What is "the imprint"?
> > > Does that mean you have to operate a web server with an
> > > "Impressum"
> > > (I guess that's the German word?) if you want to send mail?
> > > 
> > 
> > Yes I mean the german word "Impressum"
> > 
> > T-Online (or Deutsche Telekom) require that somewhere on your
> > domain is
> > your address visible. Even if you don't have a web page at all. And
> > just use the domain for sending mails.
> > 
> > 
> 
> Does this mean that if you send a mail for "u...@domain.com" from
> the 
> server "mail.example.com" with a correct FCrDNS, it will be denied 
> because domains don't match?
> If yes, this is the most stupid idea ever, as this cannot work for 
> shared mail hosting. Or maybe they have done exceptions for things
> like 
> o365 or gmail servers.

No.
Deutsche Telekom uses a whitelist which IPs can send mails to @t-
online.de accounts. They block every IP by default.

So if you got some cloud vm with a new IP address, which never before
sent mail to a @t-online.de address, mails will be rejected.
You need to write their postmasters so it gets added to their
whitelist. And for this process you need to have a small web page with
your personal address listed if your server is run privately.


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

Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"

[Renaud Allard via mailop]

On 8/27/20 8:24 AM, Felix Zielcke via mailop wrote:

Am Mittwoch, den 26.08.2020, 21:06 +0200 schrieb ml+mailop--- via
mailop:

But it was enough to have the imprint visible for them just for the


Sorry for a stupid question: What is "the imprint"?
Does that mean you have to operate a web server with an "Impressum"
(I guess that's the German word?) if you want to send mail?



Yes I mean the german word "Impressum"

T-Online (or Deutsche Telekom) require that somewhere on your domain is
your address visible. Even if you don't have a web page at all. And
just use the domain for sending mails.




Does this mean that if you send a mail for "u...@domain.com" from the 
server "mail.example.com" with a correct FCrDNS, it will be denied 
because domains don't match?
If yes, this is the most stupid idea ever, as this cannot work for 
shared mail hosting. Or maybe they have done exceptions for things like 
o365 or gmail servers.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"

[Tom Ivar Helbekkmo via mailop]

Felix Zielcke via mailop  writes:

> T-Online (or Deutsche Telekom) require that somewhere on your domain is
> your address visible. Even if you don't have a web page at all. And
> just use the domain for sending mails.

If only there were some standardized mechanism for this information...
Someone should make one, I think.  We could call it "whois".  :)

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

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

Re: [mailop] Deutsche Telekom rejects connections because of missing "provider identification"

[Felix Zielcke via mailop]

Am Mittwoch, den 26.08.2020, 21:06 +0200 schrieb ml+mailop--- via
mailop:
> > But it was enough to have the imprint visible for them just for the
> 
> Sorry for a stupid question: What is "the imprint"?
> Does that mean you have to operate a web server with an "Impressum"
> (I guess that's the German word?) if you want to send mail?
> 

Yes I mean the german word "Impressum"

T-Online (or Deutsche Telekom) require that somewhere on your domain is
your address visible. Even if you don't have a web page at all. And
just use the domain for sending mails.


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