Re: [mailop] DMARC on srs forwarding domains?

[Philip Paeps via mailop]

On 2024-02-03 09:01:40 (+0800), Bill Cole via mailop wrote:

On 2024-02-02 at 10:26:55 UTC-0500 (Fri, 2 Feb 2024 16:26:55 +0100)
Kai Bojens via mailop 
is rumored to have said:


Am 02.02.24 um 16:08 schrieb Mark E. Jeftovic via mailop:

We're having a bit of a theological debate internally on whether to 
implement DMARC on our SRS forwarder domains.


Skip SRS and implement ARC for forwarded e-mails. This should solve 
all these problems.


Telling the next hops that they need to parse ARC and trust your 
system instead of just checking SPF is a choice that one can make, 
yes.


Without SRS, SPF will fail on forwarded mail. It is going to be rare 
for anyone other than the behemoths to support ARC in any meaningful 
way for the near term (0-5 years) and you will always (effectively... 
) have sites rejecting on SPF failures out of misguided "principle."


As a forwarder, downstreams rejecting based on SPF -all really doesn't 
bother me.  In most configurations, the bounce from the downstream's 
reject message will tell the sender how to contact the recipient without 
going through the forwarder.  E.g.:


: host misconfigured.example.org[2001:db8::19:1] 
said: 550
5.7.23 : Recipient address rejected: Message 
rejected

due to: SPF fail - not authorized. Please see

http://www.openspf.net/Why?s=mfrom;id=sen...@example.net;ip=2610:1c1:1:606c::19:2;r=example.org
(in reply to RCPT TO command)

Our documentation specifically tells our downstreams to allowlist our 
forwarder:


https://docs.freebsd.org/en/articles/committers-guide/#conventions-everyone

Occasionally someone downstream complains that we should be implementing 
SRS.  We tell them to allowlist us instead, and point out that we do 
ARC.


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

Re: [mailop] DMARC on srs forwarding domains?

[Philip Paeps via mailop]

On 2024-02-02 23:08:54 (+0800), Mark E. Jeftovic via mailop wrote:
We're having a bit of a theological debate internally on whether to 
implement DMARC on our SRS forwarder domains.


The team here says that DMARC means there will never be alignment on 
an SRS forwarder domain because the envelope-from /must /match the 
mail-from.


What we're wondering is, which is better:

 * having no DMARC record because there will never be alignment (but
   there is SPF)
 * having a minimal DMARC with p=none ?

This is just for SRS forwarder domains /only/
/
/
Thoughts?


I don't think there's any point in deploying SRS in the first place...  
Rejecting purely on SPF -all is a misconfiguration.  Nobody should be 
doing that.  At best, SRS is going to score a couple of points of 
hamminess.  If a message relies on those points to be seen as ham, there 
is probably lower hanging fruit the sender needs to pick.  This 
shouldn't be a forwarder problem.


As others have mentioned: ARC is the "solution".

While SRS is purely a hack to work around misguided people 
hard-enforcing SPF -all policies, ARC actually provides meaningful 
authentication signals to downstream recipients (and forwarders).


(There is something to be said for hard-enforcing specifically "v=spf1 
-all", but policies with anything between the v=spf1 and the -all are 
overwhelmingly configuration errors, and should only count for scoring.)


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

Re: [mailop] DMARC on srs forwarding domains?

[황병희]

Hellow Kai,

On Fri, 2024-02-02 at 16:26 +0100, Kai Bojens via mailop wrote:
> Am 02.02.24 um 16:08 schrieb Mark E. Jeftovic via mailop:
> 
> > We're having a bit of a theological debate internally on whether to
> > implement DMARC on our SRS forwarder domains.
> 
> Skip SRS and implement ARC for forwarded e-mails. This should solve
> all 
> these problems.

I completely agree with this. And i know that several famous projects
have deployed ARC (RFC 8617). Linux Kernel Project, FreeBSD Project and
Postfix mailing list. Thanks!


Sincerely, Byunghee

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

Re: [mailop] DMARC on srs forwarding domains?

[Benny Pedersen via mailop]

Bill Cole via mailop skrev den 2024-02-03 02:01:

Telling the next hops that they need to parse ARC and trust your system 
instead of just checking SPF is a choice that one can make, yes.


there is nothing to tell, its trustness or not

maillist arc trustness: yes
direct to mx trustness: no

in dmarc this trustness missing support

Without SRS, SPF will fail on forwarded mail. It is going to be rare 
for anyone other than the behemoths to support ARC in any meaningful 
way for the near term (0-5 years) and you will always (effectively... ) 
have sites rejecting on SPF failures out of misguided "principle."


spf will fail, so true, but reallity is that next hop changes envelope 
sender, with you clame is a spf bug ?


sites should not reject on base of dkim, spf, or even arc, only reject 
on base of dmarc results, but many brokken software is not ready for 
dmarc yet, sadly, so in pratice only rspamd does something that works, 
but i hope for spamassassin does it well aswell


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

Re: [mailop] DMARC on srs forwarding domains?

[Bill Cole via mailop]

On 2024-02-02 at 10:26:55 UTC-0500 (Fri, 2 Feb 2024 16:26:55 +0100)
Kai Bojens via mailop 
is rumored to have said:


Am 02.02.24 um 16:08 schrieb Mark E. Jeftovic via mailop:

We're having a bit of a theological debate internally on whether to 
implement DMARC on our SRS forwarder domains.


Skip SRS and implement ARC for forwarded e-mails. This should solve 
all these problems.


Telling the next hops that they need to parse ARC and trust your system 
instead of just checking SPF is a choice that one can make, yes.


Without SRS, SPF will fail on forwarded mail. It is going to be rare for 
anyone other than the behemoths to support ARC in any meaningful way for 
the near term (0-5 years) and you will always (effectively... ) have 
sites rejecting on SPF failures out of misguided "principle."




--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [EXTERNAL]Re: Spamfolder mini rant (Was: Contact Google Postmaster) --> "Junk (suspected)" as preferred folder nam

[Randolf Richardson, Postmaster via mailop]

> On 1/29/2024 3:20 AM, Laura Atkins via mailop wrote:
> 
> > A very experienced spam filter person, who worked at a not-for-profit 
> > spam filtering company and two of the major mailbox providers once 
> > told me that the biggest challenge with their job was that there were 
> > messages that some recipients were SURE were spam and messages that 
> > some recipients absolutely wanted. Those were the hardest messages to 
> > decide what to do with. They couldn´t block them because some 
> > recipients would be mad and they couldn´t deliver them because other 
> > recipients would be mad.
> 
> Most users cannot be consistent with their own email.  One marketing 
> message about X is spam, the other is wanted email. Perhaps the second 
> dealt with a conference they were planning to attend, or dealt with a 
> product they used, while the other didn't.  Perhaps the conference sent 
> a few to many notices.  The test-retest reliability is at best in the 
> mid .9s.

This is another excellent example of how a purely technical solution 
to the spam problem will likely always fail to achieve algorithmic 
perfection.  (Heck, even human inspection by a person who doesn't 
know whether one, neither, or both of these recipients wants it.)

> I do think "Spam" and "Junk" are poor terns in that they discourage 
> checking.  Quarantine is a better term, but as has been pointed out so 
> much is junk or spam that people stop looking.

I've been using this exact folder name for many of of my clients 
(when I've been tasked with setting up their eMail client software):

Junk (suspected)

I've found that this has yielded positive results for most users 
because the inclusion of the parenthesized word "suspected" reminds 
them that the assessments that caused the routing of messages to this 
folder are lacking the characteristic of definitive certainty.

A few users have commented to me over the years that this particular 
folder name has actually been a helpful yet subtle reminder to not 
completely ignore the Junk eMail folder.

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


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

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

[Michael Sofka via mailop]

On 1/29/2024 3:20 AM, Laura Atkins via mailop wrote:

A very experienced spam filter person, who worked at a not-for-profit 
spam filtering company and two of the major mailbox providers once 
told me that the biggest challenge with their job was that there were 
messages that some recipients were SURE were spam and messages that 
some recipients absolutely wanted. Those were the hardest messages to 
decide what to do with. They couldn’t block them because some 
recipients would be mad and they couldn’t deliver them because other 
recipients would be mad.


Most users cannot be consistent with their own email.  One marketing 
message about X is spam, the other is wanted email. Perhaps the second 
dealt with a conference they were planning to attend, or dealt with a 
product they used, while the other didn't.  Perhaps the conference sent 
a few to many notices.  The test-retest reliability is at best in the 
mid .9s.


I do think "Spam" and "Junk" are poor terns in that they discourage 
checking.  Quarantine is a better term, but as has been pointed out so 
much is junk or spam that people stop looking.


Michael

--
Michael D. Sofka   sof...@rpi.edu
ITI Software Architect,   Email, TeX, QIS, Epistemology
Rensselaer Polytechnic Institute, Troy, NY.

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

Re: [mailop] DMARC on srs forwarding domains?

[Kai Bojens via mailop]

Am 02.02.24 um 16:08 schrieb Mark E. Jeftovic via mailop:

We're having a bit of a theological debate internally on whether to 
implement DMARC on our SRS forwarder domains.


Skip SRS and implement ARC for forwarded e-mails. This should solve all 
these problems.


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

Re: [mailop] Support contact for Shaw.ca

[Andrew C Aitchison via mailop]

On Thu, 1 Feb 2024, Scott Undercofler via mailop wrote:


I'm replying on list for visibility. The issue you’re seeing is
directly related to SMTP smuggling which was discussed on list ad
nauseam about a month ago. The servers at shaw are configured to
reject non-RFC bare linefeeds. Can you elaborate on why you’re
sending them as they are not allowed.


On Feb 1, 2024, at 5:52 PM, Hugh E Cruickshank via mailop  
wrote:

We are experiencing a problem with mail delivery to Shaw.ca. Since
January 18th messages have been bounced with: 552 5.2.0 Message contains
bare CR and is violating 822.bis section 2.3. We have tried to contact
postmas...@shaw.ca but have not received any response yet. I was
wondering if there was anyone on this list who could provide a support
contact at shaw.ca that might be able assist us with identifying and
correcting this issue.


If Hugh's problem is indeed bare linefeeds, your bounce message may be
leading him astray by suggesting he has sent bare carriage-returns.

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

[mailop] DMARC on srs forwarding domains?

[Mark E. Jeftovic via mailop]

We're having a bit of a theological debate internally on whether to 
implement DMARC on our SRS forwarder domains.


The team here says that DMARC means there will never be alignment on an 
SRS forwarder domain because the envelope-from /must /match the mail-from.


What we're wondering is, which is better:

 * having no DMARC record because there will never be alignment (but
   there is SPF)
 * having a minimal DMARC with p=none ?

This is just for SRS forwarder domains /only/
/
/
Thoughts?

- mark
/
/
--
Mark E. Jeftovic 
Co-founder & CEO easyDNS Technologies Inc.
+1-(416)-535-8672 ext 225

/"Never expect a thing you do not want,
and never desire a thing you do not expect."
-- Bob Proctor /___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Support contact for Shaw.ca

[Gellner, Oliver via mailop]

On 02.02.2024 at 01:52 Hugh E Cruickshank via mailop wrote
> We are experiencing a problem with mail delivery to Shaw.ca. Since January 
> 18th messages have been bounced with: 552 5.2.0 Message contains bare CR and 
> is violating 822.bis section 2.3. We have tried to contact postmas...@shaw.ca 
> but have not received any response yet. I was wondering if there was anyone 
> on this list who could provide a support contact at shaw.ca that might be 
> able assist us with identifying and correcting this issue.
> Any suggestions would be greatly appreciated.

Does the message contain a bare carriage return? If so you don't need to 
contact anyone, because the message is syntactically broken and needs to be 
fixed:
https://www.rfc-editor.org/rfc/rfc2822#section-2.3
> CR and LF MUST only occur together as CRLF; they MUST NOT appear 
> independently in the body.

Depending on your MTA you can enable debug logs or redirect/duplicate the 
message into a local mailbox to check its body.
Maybe you can also configure your MTA so that it does not accept such messages 
in the first place and is then stuck with them.

--
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] Ooops - sorry

[Hans-Martin Mosner via mailop]

Am 02.02.24 um 04:03 schrieb Lou Katz via mailop:

Wound up way back in my archive and responded to an old, dead issue.


If only the issue were as dead as it is old... SPF is a PITA that stays.

:-)
Hans-Martin


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