Re: [mailop] Partial issues forwarding mails to gmail.com

[Dave Anderson via mailop]

And even when it's possible it's not always desirable. An organization 
I'm involved with has many @ email aliases which 
forward to the person(s) responsible for those functions. This is 
convenient for people who need to communicate with us since they don't 
have to hunt for the responsible person(s) and their email address(es), 
and is convenient for us since we can easily change the forwarding when 
who is responsible for a function changes.

Dave

On Fri, 25 Nov 2022, Philip Paeps via mailop wrote:

> On 2022-11-25 07:28:03 (+0800), Michael Peddemors via mailop wrote:
>> Of course, one thing not mentioned on this thread..
>>
>> Simply stop allowing remote forwarding..
>>
>> Every modern email client can check multiple email accounts.
>> The day when remote forwarding was a necessity has now passed, and now 
>> with things like SPF and other email tests, forwarding simply breaks..
>>
>> Stop allowing remote forwarding, and reduce support ;)
>>
>> Not so tongue in cheek.. Local forwarding is one thing, remote 
>> forwarding for end users.. not so much.
>>
>> And, you would be surprised how many customer might just prefer using 
>> your email services to Gmail's.
>
> This is not always possible.
>
> Wearing my postmas...@freebsd.org hat: we don't want to store users' 
> mail.  We also don't want to decide for our users who should be storing 
> their email.  So we give them a choice to forward it to their mailbox 
> provider of choice.
>
> I realise we're not a representative use case but I'm sure we're not 
> alone.
>
> There are legitimate use cases for remote forwarding.
>
> Philip
>
>

-- 
Dave Anderson

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

Re: [mailop] Partial issues forwarding mails to gmail.com

[Philip Paeps via mailop]

On 2022-11-25 07:28:03 (+0800), Michael Peddemors via mailop wrote:

Of course, one thing not mentioned on this thread..

Simply stop allowing remote forwarding..

Every modern email client can check multiple email accounts.
The day when remote forwarding was a necessity has now passed, and now 
with things like SPF and other email tests, forwarding simply breaks..


Stop allowing remote forwarding, and reduce support ;)

Not so tongue in cheek.. Local forwarding is one thing, remote 
forwarding for end users.. not so much.


And, you would be surprised how many customer might just prefer using 
your email services to Gmail's.


This is not always possible.

Wearing my postmas...@freebsd.org hat: we don't want to store users' 
mail.  We also don't want to decide for our users who should be storing 
their email.  So we give them a choice to forward it to their mailbox 
provider of choice.


I realise we're not a representative use case but I'm sure we're not 
alone.


There are legitimate use cases for remote forwarding.

Philip

--
Philip Paeps
Senior Reality Engineer
Alternative Enterprises
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Partial issues forwarding mails to gmail.com

[Michael Peddemors via mailop]

Of course, one thing not mentioned on this thread..

Simply stop allowing remote forwarding..

Every modern email client can check multiple email accounts.
The day when remote forwarding was a necessity has now passed, and now 
with things like SPF and other email tests, forwarding simply breaks..


Stop allowing remote forwarding, and reduce support ;)

Not so tongue in cheek.. Local forwarding is one thing, remote 
forwarding for end users.. not so much.


And, you would be surprised how many customer might just prefer using 
your email services to Gmail's.


On 2022-11-24 11:53, Hans-Martin Mosner via mailop wrote:

Am 24.11.22 um 17:20 schrieb Martin Flygenring via mailop:
... [Google says] Our system has detected an unusual rate of 
unsolicited mail originating from your IP address.

...
Now, the interesting part is that for almost 98% of the mails 
currently in queue, Google is the original sender of the email.


I don't see a contradiction here. Google is a massive sender of spam, so 
it would only be normal to classify their email as unsolicited...


Cheers (somewhat tongue-in-cheek),
Hans-Martin

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



--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

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

Re: [mailop] Partial issues forwarding mails to gmail.com

[Antoine Minoux via mailop]

Hey Martin,

Just my two cents from running a service dedicated to email forwarding;
We've been getting a lot of help from the community recently, so I thought
I'd contribute as well.

We're often seeing this type of error, and I agree with what Jarland has
said previously. Gmail only flags the specific IP of the relays you are
using to deliver emails, which explains why only a few emails get picked up
out of millions sent per month. I'd do a few things:


   1. Find the IP addresses that are constantly getting rejected. I bet you
   have 2 or 3 IPs that soft-bounce 100% of emails.

   2. Try to investigate when it started happening (i.e. getting the first
   4.2.1 messages) and see if there was something you forwarded that Gmail
   could have picked up as obviously malicious or spammy. That's subjective,
   but sometimes it'll just be evident.

   3. Retire the blocked IPs temporarily (we've found that waiting at least
   a week and restarting slowly works well), or at least prevent them from
   delivering to Gmail. It also doesn't hurt to fill Google's Bulk Sender
   contact form
   ,
although
   it's quite an opaque process, and you won't ever get an answer - even if
   they take action.


Hope that helps,
Antoine

On Thu, Nov 24, 2022 at 8:57 PM Hans-Martin Mosner via mailop <
mailop@mailop.org> wrote:

> Am 24.11.22 um 17:20 schrieb Martin Flygenring via mailop:
> > ... [Google says] Our system has detected an unusual rate of unsolicited
> mail originating from your IP address.
> > ...
> > Now, the interesting part is that for almost 98% of the mails currently
> in queue, Google is the original sender of the
> > email.
>
> I don't see a contradiction here. Google is a massive sender of spam, so
> it would only be normal to classify their email
> as unsolicited...
>
> Cheers (somewhat tongue-in-cheek),
> Hans-Martin
>
> ___
> 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] Partial issues forwarding mails to gmail.com

[Hans-Martin Mosner via mailop]

Am 24.11.22 um 17:20 schrieb Martin Flygenring via mailop:

... [Google says] Our system has detected an unusual rate of unsolicited mail 
originating from your IP address.
...
Now, the interesting part is that for almost 98% of the mails currently in queue, Google is the original sender of the 
email.


I don't see a contradiction here. Google is a massive sender of spam, so it would only be normal to classify their email 
as unsolicited...


Cheers (somewhat tongue-in-cheek),
Hans-Martin

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

Re: [mailop] Partial issues forwarding mails to gmail.com

[Jarland Donnell via mailop]

I have noticed that one of the most consistently rejected emails when 
forwarded to Gmail, is an email from Google. I just rotate outbound IPs 
on that message using ZoneMTA and it'll get through. Waiting for an IP 
to clear a rate limit with Gmail just seems like bad business at this 
point.


On 2022-11-24 10:20, Martin Flygenring via mailop wrote:

Hello all

For the past few weeks, we've noticed increasing queues on our 
MX-servers when forwarding some emails to our users alternate 
addresses, if that forwarding address is a gmail.com address. Most of 
the mails go through without issues, but some end up getting deferred 
with the error message:
    421 4.7.28 [185.164.14.118 15] Our system has detected an unusual 
rate of unsolicited mail originating from your IP address. To protect 
our users from spam, mail sent from your IP address has been 
temporarily rate limited. Please visit 
https://support.google.com/mail/?p=UnsolicitedRateLimitError to review 
our Bulk Email Senders Guidelines. 
bj3-20020a170902850300b001895e356f00si917651plb.152 - gsmtp (in reply 
to EOD command)


Now, the interesting part is that for almost 98% of the mails currently 
in queue, Google is the original sender of the email.


Total mails deferred/in queue due to the above message, at the time of 
writing: 2696

Top 3 original sender:
   2582 gmail.com
 38 google.com
 22 calendar-server.bounces.google.com

For reference, we currently have 2.8m registered domains, meaning we 
send millions of mails towards gmail on a monthly basis.
So while it is a very small amount of mails that end up in this state, 
we are still puzzled about why. Especially when so many of the original 
senders are gmail-addresses or other Google addresses.


I have been looking through our queues, and most often it looks like 
very legit mails that gmail just doesn't want to accept. For example:

- Friends talking about a christmas lunch/dinner
- Someone who's heating at home isn't working
- Some friends talking about a LEGO build they're doing together
- Building management meetings
- Someone that's sad they can't join a presentation because they're on 
vacation

.. and so on. Very innocent stuff.

We use SRS when forwarding, and every forward that users set up 
requires verification by the forward recipient, by them clicking a link 
to confirm they want to accept these forwards.


Looking at our graphs, between Oct 25th and Nov 7th we had 16 mails get 
deferred/bounce because of the above error message. Since Nov 8th, 
we're looking at somewhere between 250 and 1000 mails pr. day. 
Sometimes the mail eventually goes through with delay, but there are 
some that never make it through.


Is anyone else seeing similar issues when forwarding mails from 
gmail.com, back to other addresses at gmail.com?

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

[mailop] Partial issues forwarding mails to gmail.com

[Martin Flygenring via mailop]

Hello all

For the past few weeks, we've noticed increasing queues on our 
MX-servers when forwarding some emails to our users alternate addresses, 
if that forwarding address is a gmail.com address. Most of the mails go 
through without issues, but some end up getting deferred with the error 
message:
    421 4.7.28 [185.164.14.118 15] Our system has detected an unusual 
rate of unsolicited mail originating from your IP address. To protect 
our users from spam, mail sent from your IP address has been temporarily 
rate limited. Please visit 
https://support.google.com/mail/?p=UnsolicitedRateLimitError to review 
our Bulk Email Senders Guidelines. 
bj3-20020a170902850300b001895e356f00si917651plb.152 - gsmtp (in reply to 
EOD command)


Now, the interesting part is that for almost 98% of the mails currently 
in queue, Google is the original sender of the email.


Total mails deferred/in queue due to the above message, at the time of 
writing: 2696

Top 3 original sender:
   2582 gmail.com
 38 google.com
 22 calendar-server.bounces.google.com

For reference, we currently have 2.8m registered domains, meaning we 
send millions of mails towards gmail on a monthly basis.
So while it is a very small amount of mails that end up in this state, 
we are still puzzled about why. Especially when so many of the original 
senders are gmail-addresses or other Google addresses.


I have been looking through our queues, and most often it looks like 
very legit mails that gmail just doesn't want to accept. For example:

- Friends talking about a christmas lunch/dinner
- Someone who's heating at home isn't working
- Some friends talking about a LEGO build they're doing together
- Building management meetings
- Someone that's sad they can't join a presentation because they're on 
vacation

.. and so on. Very innocent stuff.

We use SRS when forwarding, and every forward that users set up requires 
verification by the forward recipient, by them clicking a link to 
confirm they want to accept these forwards.


Looking at our graphs, between Oct 25th and Nov 7th we had 16 mails get 
deferred/bounce because of the above error message. Since Nov 8th, we're 
looking at somewhere between 250 and 1000 mails pr. day. Sometimes the 
mail eventually goes through with delay, but there are some that never 
make it through.


Is anyone else seeing similar issues when forwarding mails from 
gmail.com, back to other addresses at gmail.com?



--
Martin Flygenring (maf)
Systems Engineer, One.com

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

Re: [mailop] Another interesting batch of suspicious activity on an IPXO network..

[Jarland Donnell via mailop]

When I first tested the IPXO network they required me to pay them a 
custom fee to exclude my services from their internal mail scanner. They 
would otherwise downgrade connections from SSL and intercept the SMTP 
traffic, then scan the contents of emails for spam. I can't imagine that 
still functions given the amount of spam sent from their networks, and 
most companies that deploy systems like that purchase very expensive 
appliances rather than build their own, which would be quite a waste of 
money to just give up on so quickly.


Anyone from IPXO on the list that might explain what the network 
operators are doing to combat spam these days?


On 2022-11-24 09:40, Michael Peddemors via mailop wrote:

I don't think all these companies are operating on this network..

Eg..

host -t TXT hostedexchange.co.il
hostedexchange.co.il descriptive text "v=spf1 ip4:212.143.142.84 
ip4:194.90.28.61 -all"


Obvious attempts to hide activity using legitimate companies?

#   84.32.92.41   mail01.info.messe-muenchen.de
#   84.32.92.6 1   mail.suminet.com
#   84.32.92.131   out3.mail.studentaid.gov
#   84.32.92.141   out4.mail.studentaid.gov
#   84.32.92.161   out9.mail.studentaid.gov
#   84.32.92.181   out2.mail.studentaid.gov
#   84.32.92.221   stl-mta-dmz-02-pub.dol.gov
#   84.32.92.301   mail.bpd.ci.buffalo.ny.us
#   84.32.92.362   lmta224.e.sharkninja.com
#   84.32.92.401   mail.beind.com
#   84.32.92.421   mail2.cncloud.co.il
#   84.32.92.451   kinneret4.kinneret.co.il
#   84.32.92.461   relay2.mpv.co.il
#   84.32.92.481   mail.hishtil.com
#   84.32.92.501   owa.s-wear.co.il
#   84.32.92.531   webstore.od.co.il
#   84.32.92.561   mail.gestec.co.il
#   84.32.92.621   smtp.hostedexchange.co.il
#   84.32.92.651   mail.almog-ltd.com
#   84.32.92.771   mail69.publicators.com
#   84.32.92.801   fbsnd01104-jc.im.kddi.ne.jp
#   84.32.92.831   fbsnd01101-jc.im.kddi.ne.jp

.. might as well include the rest, in case someone on the list operates 
one of these domains..


84.32.92.851   snd00102-jc.im.kddi.ne.jp
   84.32.92.881   echtclxmr12ac10.ech.jpx.co.jp
   84.32.92.891   echtclxmr11ac10.ech.jpx.co.jp
   84.32.92.981   jmg2-aq.joshin.co.jp
   84.32.92.991   jmg2-ap.joshin.co.jp
   84.32.92.101   1   jmg2-an.joshin.co.jp
   84.32.92.103   1   jmg2-al.joshin.co.jp
   84.32.92.106   1   jmg-ao.joshin.co.jp
   84.32.92.107   1   jmg-an.joshin.co.jp
   84.32.92.113   1   john2.cantamen.de
   84.32.92.116   1   mout01.cdn.csl-computer.net
   84.32.92.117   1 
dwn-thor.deutsche-wirtschafts-nachrichten.de

   84.32.92.122   1   dev.otec.org
   84.32.92.126   1   mailer.acog.org
   84.32.92.137   1   e-bind.us
   84.32.92.142   1   ozmtabm02.ms.com
   84.32.92.146   1   ozmtaint01.ms.com
   84.32.92.154   1   mail01.www-101.aig.com
   84.32.92.159   2   mail1611.isramail.co.il
   84.32.92.162   1   mail03.marketing.nuance.com
   84.32.92.165   1   mail03.info.messe-muenchen.de
   84.32.92.167   1   gg9.uniki.de
   84.32.92.168   1   mail.balkanautomotive.rs
   84.32.92.173   1   dedi138.your-server.de
   84.32.92.182   1   gateway.rocketmarketing.it
   84.32.92.184   1   nl-he-1.abelssoft.de
   84.32.92.189   1   auris.cityhost.com.ua
   84.32.92.191   1   mailgw2.solucionait.com
   84.32.92.192   1   mx.dominos.ua
   84.32.92.199   1   a-06.wlk-msg.de
   84.32.92.201   1   gateway.sxm.it
   84.32.92.210   1   mta27-87.sears.com
   84.32.92.211   1   mta26-87.sears.com
   84.32.92.220   1   mta16-87.toms.com
   84.32.92.221   1   vmta15.87.lstrk.net
   84.32.92.223   1   vmta13.87.lstrk.net
   84.32.92.224   1   vmta12.87.lstrk.net
   84.32.92.227   1   vmta255.86.lstrk.net
   84.32.92.230   1   vmta249.86.lstrk.net
   84.32.92.233   1   vmta245.86.lstrk.net
   84.32.92.235   1   vmta243.86.lstrk.net
   84.32.92.239   1   vmta238.86.lstrk.net
   84.32.92.243   1   vmta234.86.lstrk.net
   84.32.92.246

[mailop] Another interesting batch of suspicious activity on an IPXO network..

[Michael Peddemors via mailop]

I don't think all these companies are operating on this network..

Eg..

host -t TXT hostedexchange.co.il
hostedexchange.co.il descriptive text "v=spf1 ip4:212.143.142.84 
ip4:194.90.28.61 -all"


Obvious attempts to hide activity using legitimate companies?

#   84.32.92.41   mail01.info.messe-muenchen.de
#   84.32.92.6 1   mail.suminet.com
#   84.32.92.131   out3.mail.studentaid.gov
#   84.32.92.141   out4.mail.studentaid.gov
#   84.32.92.161   out9.mail.studentaid.gov
#   84.32.92.181   out2.mail.studentaid.gov
#   84.32.92.221   stl-mta-dmz-02-pub.dol.gov
#   84.32.92.301   mail.bpd.ci.buffalo.ny.us
#   84.32.92.362   lmta224.e.sharkninja.com
#   84.32.92.401   mail.beind.com
#   84.32.92.421   mail2.cncloud.co.il
#   84.32.92.451   kinneret4.kinneret.co.il
#   84.32.92.461   relay2.mpv.co.il
#   84.32.92.481   mail.hishtil.com
#   84.32.92.501   owa.s-wear.co.il
#   84.32.92.531   webstore.od.co.il
#   84.32.92.561   mail.gestec.co.il
#   84.32.92.621   smtp.hostedexchange.co.il
#   84.32.92.651   mail.almog-ltd.com
#   84.32.92.771   mail69.publicators.com
#   84.32.92.801   fbsnd01104-jc.im.kddi.ne.jp
#   84.32.92.831   fbsnd01101-jc.im.kddi.ne.jp

.. might as well include the rest, in case someone on the list operates 
one of these domains..


84.32.92.851   snd00102-jc.im.kddi.ne.jp
   84.32.92.881   echtclxmr12ac10.ech.jpx.co.jp
   84.32.92.891   echtclxmr11ac10.ech.jpx.co.jp
   84.32.92.981   jmg2-aq.joshin.co.jp
   84.32.92.991   jmg2-ap.joshin.co.jp
   84.32.92.101   1   jmg2-an.joshin.co.jp
   84.32.92.103   1   jmg2-al.joshin.co.jp
   84.32.92.106   1   jmg-ao.joshin.co.jp
   84.32.92.107   1   jmg-an.joshin.co.jp
   84.32.92.113   1   john2.cantamen.de
   84.32.92.116   1   mout01.cdn.csl-computer.net
   84.32.92.117   1 
dwn-thor.deutsche-wirtschafts-nachrichten.de

   84.32.92.122   1   dev.otec.org
   84.32.92.126   1   mailer.acog.org
   84.32.92.137   1   e-bind.us
   84.32.92.142   1   ozmtabm02.ms.com
   84.32.92.146   1   ozmtaint01.ms.com
   84.32.92.154   1   mail01.www-101.aig.com
   84.32.92.159   2   mail1611.isramail.co.il
   84.32.92.162   1   mail03.marketing.nuance.com
   84.32.92.165   1   mail03.info.messe-muenchen.de
   84.32.92.167   1   gg9.uniki.de
   84.32.92.168   1   mail.balkanautomotive.rs
   84.32.92.173   1   dedi138.your-server.de
   84.32.92.182   1   gateway.rocketmarketing.it
   84.32.92.184   1   nl-he-1.abelssoft.de
   84.32.92.189   1   auris.cityhost.com.ua
   84.32.92.191   1   mailgw2.solucionait.com
   84.32.92.192   1   mx.dominos.ua
   84.32.92.199   1   a-06.wlk-msg.de
   84.32.92.201   1   gateway.sxm.it
   84.32.92.210   1   mta27-87.sears.com
   84.32.92.211   1   mta26-87.sears.com
   84.32.92.220   1   mta16-87.toms.com
   84.32.92.221   1   vmta15.87.lstrk.net
   84.32.92.223   1   vmta13.87.lstrk.net
   84.32.92.224   1   vmta12.87.lstrk.net
   84.32.92.227   1   vmta255.86.lstrk.net
   84.32.92.230   1   vmta249.86.lstrk.net
   84.32.92.233   1   vmta245.86.lstrk.net
   84.32.92.235   1   vmta243.86.lstrk.net
   84.32.92.239   1   vmta238.86.lstrk.net
   84.32.92.243   1   vmta234.86.lstrk.net
   84.32.92.246   1   vmta231.86.lstrk.net

--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email

Re: [mailop] SPF (and other email security protocols) Survey

[G. Miliotis via mailop]

On 2022-11-24 14:01, Tobias Fiebig via mailop wrote:


And to circle back to on-topic: The result of that is what then pops up in 
/var/log/maillog.
So it isn't about 'should VT change [something]'; It is more 'shouldn't society 
change the incentive structure and general setup around academia as a whole'?
I have quite some opinions there, boiling down to the answers 'yes' (and 
suspect most here will agree with that).
But that is not really in my power; So I try to do what I can instead 
(channeling results of the system into a more manageable frame, while trying to 
teach those students I directly work with at the institution I am at).


At the risk of being frowned down upon for this for being arguably off 
topic or mean-spirited, I feel I must venture an opinion, even as a tiny 
operator, because I have had extensive experience with how academia 
works and have dealt with this repeatedly.


This "oh what can I do, woe is me" responsibility-diffusing rhetoric 
belongs with junior, recently hired teaching assistants, not professors 
with tenure. Isn't it professors who, after all, in fact run the 
universities? Who provides and sets the academic standards and 
practices, if not they? Who populates the commitees? Or do we further 
diffuse responsibility for bad research practices up to the govenment, 
another academic trope? Who is this "academia"?


How about a more honest: "This is how the questionnaire is and will 
remain, we have no time to change it now, feel free to not fill it in. 
We'll do better next time" and be done with it? Because I didn't see any 
willingness to change something in the questionnaire in light of the 
criticism in this forum.

* How about adding info to/changing the upfront consent statement?
* Making questions optional is not really confidence-inspiring, feels 
like a quick fix solution to "get on with it", a practice I've seen used 
when there is no time to go over and redo a questionnaire due to having 
to get it through committees again.
* You claimed GDPR work was done. Is surveymonkey more GDPR-compliant 
than Google forms? How about using your own self-hosted platform, for 
example? They're zero cost, secure and easy to set up and I would trust 
something you self-manage more. Surely you have the know-how.


All that said, I am all for research on the subject of mail protocols 
and practice and sincerely hope this work produces useful results, 
hopefully also truly representative of practice in the field. Good luck 
to you.


Best Regards,
G. Miliotis


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

Re: [mailop] SPF (and other email security protocols) Survey

[Tobias Fiebig via mailop]

Hello Andrew
> If VT PhD students don't have the experience needed in the topics they study, 
> then shouldn't VT change either the students or the topics ?
As I said, this is not about specific instances, people, or VT in particular.

It is more of an observation that while in 1988, you could go through 
RFC1031-1035 and have a rather complete overview of DNS (picked as an example 
here).

That changed since then, not only for DNS; Mail, TCP,... they all grew. A lot.

At the same time--sticking with DNS here--countless ways of 'holding it wrong' 
emerged in practice, far beyond RFC1537 and RFC1912. 
And to do proper measurements (in terms of 'not unethical' and imho also in 
terms of 'actually reliable') you MUST know all of this.
When I look at the people with whom I graduated my master, who went on to work 
on DNS implementations:
They spent _at least_ as much (likely more) time on DNS alone as I did on my 
whole PhD.
And a PhD comes with a lot of other things added to it (teaching, funding, 
different topics); It is more like a mixed bag of beans.
And still they will _always_ know more about DNS than me.

Which brings us to the academic-philosophical point: Technically, I would 
expect a PhD to be exactly about that: 
Having the time to _really_ dig into something, getting to the bottom of it, 
and making meaningful contributions to the state of knowledge; if it takes five 
years, a decade, or more.
But then again, as said earlier in this thread, I tend to be a bit (too) 
idealistic.
Nevertheless, from your message, I believe that we actually agree on this.

Closing the loop: Academia has grown into an output focused, measured, and 
managed ecosystem in many places*.
People have 4 (EU) to 6 (US-ish) Years for a PhD, with an expectations of 3-5 
papers in well regarded venues.
There is simply not the time for engaging sufficiently deeply with many 
technologies, and--throwing another punch here--I think many CS BSc/MSC 
programs also do not necessarily provide the right foundation for that.
Teaching is another chore many faculty run through, while all things fall of 
different corners of the plate at the same time (and far too often faculty 
members' mental health as well; Burnout in academia is a thing).

And to circle back to on-topic: The result of that is what then pops up in 
/var/log/maillog.
So it isn't about 'should VT change [something]'; It is more 'shouldn't society 
change the incentive structure and general setup around academia as a whole'?
I have quite some opinions there, boiling down to the answers 'yes' (and 
suspect most here will agree with that).
But that is not really in my power; So I try to do what I can instead 
(channeling results of the system into a more manageable frame, while trying to 
teach those students I directly work with at the institution I am at).

In any case, I believe that harsh words when something (predictably and 
repeatedly) goes wrong with that system in place will not bring us closer to a 
solution.

With best regards,
Tobias

*I am not really planning to make a full argument on why I believe that this 
approach is really detrimental to the acquisition of knowledge and education of 
students; It is beyond the scope of this ML, and I assume I'd be preaching to 
the choir. If you are more interested in this, I can recommend a (somewhat 
recent) measurement study of mine into/tangential to the topic; The discussion 
actually touches on some of these points, and provides good pointers to further 
work on it: https://arxiv.org/abs/2104.09462 

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

Re: [mailop] SPF (and other email security protocols) Survey

[Andrew C Aitchison via mailop]

On Wed, 23 Nov 2022, Tobias Fiebig via mailop wrote:


We can have an awful lot of discussions about this, and there is
a lot going on; Besides the obvious 'is it good or not' and 'is
this really science?', we essentially deal with 'science' with
all its incentives (publish or perish); This means trying to do
research on Internet protocols that have been around for longer
than the combined age of the PI and PhD in many cases; PhDs fall
out of their masters before getting into such a topic, and then
essentially have a year to know all the ins and out of a protocol
that grew over the past 40 years... because after the first year
they _should_ basically have their first paper under
submission. Certainly people that haven't run their own
mailserver/authNSes for more than a decade. Yes, recipe for
disaster.


IIUC the first PhD candidates were not raw graduates but experiences
practitioners in their field; a PhD as a research training came later.

Although I *did* start a PhD in Maths/Computer Graphics straight after my 
BSc., my brother worked as a hospital doctor for several years after qualify

before starting his MD (which not the standard medical degree in the UK)
and a friend of my wife's practiced alternative medicine for many years before
starting a PhD in that area.

If VT PhD students don't have the experience needed in the topics they study,
then shouldn't VT change either the students or the topics ?

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Massive bounce report campaign

[Hans-Martin Mosner via mailop]

24. November 2022 08:48, "Cyril - ImprovMX via mailop" mailto:mailop@mailop.org?to=%22Cyril%20-%20ImprovMX%20via%20mailop%22%20)>
 schrieb:
I'd love to be able to drop them, but the situation is made in a way 
that we can not do anything:
That user configured their bounce domain to pass through us, but we didn't send 
their bouncing email in the first place. they use another service for that.
So there's still a lot you can do:
* reject mail destined for their bounce domain at the SMTP level, that 
still consumes resources but not as much as trying to queue and forward it.
* if you have valid contact details (and if they are your customer, you 
should have those), get them on the phone and make it crystal clear to them 
that their spam campaign needs to stop immediately.
* you might choose to exercise legal options to have them pay damages 
for interfering with your business. I'm in no way legal expert for any 
jurisdiction, so you'd need to discuss this with your lawyer.
Sadly, Outlook/Hotmail/Microsoft might be the least helpful in all of 
this. They are too big to care.

Cheers,

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