Re: [mailop] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Felix Fontein via mailop]

Hi,

> > the conclusions at that time were:
> > [...] > - It only affects domains on the Public Suffix List. i.e.
> > the sender domain is in some public namespace where Y! want to see
> > an SOA to show it's actually administered by someone.
> > 
> > Is that the case for you?  
> 
> No. I might as well reveal the actual domain names involved, since
> it's not particularly secret: it's "westfir.or.us" and
> "ci.westfir.or.us".
> 
> Neither of those are on the public suffix list, although "or.us" is.
> 
> Mail from *@ci.westfir.or.us is accepted if ci.westfir.or.us has an
> SOA record, and not accepted if it doesn't.
> 
> So if it's supposed to be only checking at delegated breakpoints on
> the PSL, it appears it has a bug, because there's no break between
> those two (unless I'm missing something obvious)?

right now there is only a SOA record for `us.` itself and for
`ci.westfir.or.us.`, but for nothing inbetween. Since both `us.` and
`or.us.` are public suffixes, Y! seems to expect a SOA record
somewhere below these two, so for `westfir.or.us.` or
`ci.westfir.or.us.` (or both).

Cheers,
Felix

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

Re: [mailop] Guide for setting up a mail server ?

[K. M. Peterson via mailop]

On Sun, Jul 9, 2023 at 18:52 John Levine via mailop 
wrote:

> A friend of mine wants to set up a mail server on a VPS and asked me what
> he needs to do beyond the obvious setting up postfix and dovecot.  Is there
> a good summary somewhere?


So, at the risk of totally missing the point, I’ll add a different branch.
Sadly, from some experience…

1. There is a management element missing in these discussions. How does
your friend plan to maintain credentials for those using his service?
There isn’t really any in-protocol way to, for example, allow an end-user
to change their password.

2. Supporting people configuring their mail clients - documenting how to
set up Mac Mail.app/Thunderbird/Outlook, etc.  Bit of work there, too.

3.  Spamassassin setup?  Decisions on marking or automatically (sieve?)
routing to a Junk mailbox, or even dropping - assuming you reject what you
can before spooling the message data.

4. Managing space, automating Trashes deletion, backups.  Ayeee, and people
expect vacation responders.  I’ll bet that is another thread that I’m not
going to pick up.

Clearly to this point there has been lots of good discussion in the weeds
(and this IS the mailop list, after all) but I’ve set up a couple of these
and found I spent a whole lot of time on, er, “details” like this.
Offering access via a web-based UI will fix some but not all of these
issues, of course, but the intended user base may need consideration at a
different level.

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

Re: [mailop] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Robert L Mathews via mailop]

On 7/12/23 4:22 PM, Andy Smith via mailop wrote:


We last had this thread back in may


Yikes; not sure how I missed that. Thanks for the pointer.



the conclusions at that time were:
[...] > - It only affects domains on the Public Suffix List. i.e. the sender
   domain is in some public namespace where Y! want to see an SOA to
   show it's actually administered by someone.

Is that the case for you?


No. I might as well reveal the actual domain names involved, since it's 
not particularly secret: it's "westfir.or.us" and "ci.westfir.or.us".


Neither of those are on the public suffix list, although "or.us" is.

Mail from *@ci.westfir.or.us is accepted if ci.westfir.or.us has an SOA 
record, and not accepted if it doesn't.


So if it's supposed to be only checking at delegated breakpoints on the 
PSL, it appears it has a bug, because there's no break between those two 
(unless I'm missing something obvious)?


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

Re: [mailop] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Andy Smith via mailop]

Hi,

On Wed, Jul 12, 2023 at 03:38:05PM -0700, Robert L Mathews via mailop wrote:
> see https://postmaster.yahooinc.com/error-codes
> 
> According to that page,
> 
> "- These errors indicate that the domain used to the right of the @ in the
> MAIL FROM does not appear to be a real domain.
> - We determine if the domain name exists by using an SOA query; therefore,
> if multiple subdomains are used in MAIL FROM commands, then besides setting
> up a DNS A or MX record (perhaps using a wildcard), then SOA records must be
> set up as well."
> 
> This is surprising!

We last had this thread back in may and the conclusions at that
time were:

- This is intentional and documented

- It only affects domains on the Public Suffix List. i.e. the sender
  domain is in some public namespace where Y! want to see an SOA to
  show it's actually administered by someone.

Is that the case for you?

The thread is here (login required):

https://list.mailop.org/private/mailop/2023-May/025051.html

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Guide for setting up a mail server ?

[Michael Peddemors via mailop]

On 2023-07-12 12:53, Jaroslaw Rafa via mailop wrote:

Most of regular consumer email users don't have any reason for this. As Bill
Cole, whom I was replying to, wrote - nobody would try to impersonate you or
me in a phishing campaign for financial gain, because there won't be any.


hehehe.. they do it all the time.. It's your contacts that will fall for 
it, and it will probably be to place a trojan.. and clean out THEIR 
data, and banking information..


Trust me, fought the whole SPF for a long while, it was 1/2 baked.. but 
when a bank or a large instition publicizes a clean SPF record.. honour 
it.. they will be forged more..


And yes, email forwarding will break.. but email forwarding remotely 
should be killed off anyways.. everyone can log into two accounts.


Going back to slaying dragons.. This thread is getting a bit off the 
original posters question.


--
"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

[mailop] AOL/Yahoo requiring SOA record for MAIL FROM domain name?

[Robert L Mathews via mailop]

Today I had a customer complain that mail they send to AOL or Yahoo 
addresses was being returned with:


451 Message temporarily deferred due to unresolvable RFC.5321 from 
domain; see https://postmaster.yahooinc.com/error-codes


According to that page,

"- These errors indicate that the domain used to the right of the @ in 
the MAIL FROM does not appear to be a real domain.
- We determine if the domain name exists by using an SOA query; 
therefore, if multiple subdomains are used in MAIL FROM commands, then 
besides setting up a DNS A or MX record (perhaps using a wildcard), then 
SOA records must be set up as well."


This is surprising!

Aside from anything else, it implies that SOA records can be easily 
added to solve this, similar to how you add MX or A records. But that is 
usually not the case: SOA records can exist only at a DNS zone 
delegation boundary, not at the level of any arbitrary hostname.


I know AOL/Yahoo folks are on here. IS it intentional to be this 
restrictive, effectively introducing a new DNS requirement for mail 
senders? If so, this is going to be a problem for many people.


To give a concrete example of the difficulty, we host mail and DNS for 
"cityname.or.us". Our system generates a DNS zone file that originally 
looked like:


 $ORIGIN cityname.or.us
 @  SOA   ns1.tigertech.net. a.tigertech.net. ( 1 2 3 4 5 )
 @  MX 0  mx.tigertech.net.
 @  A 192.0.2.44
 @  (SPF and DKIM records omitted for brevity)

This works for mail sent from "addr...@cityname.or.us".

After a while, the customer decided they also wanted to send mail from 
addresses like "addr...@ci.cityname.or.us". So we added the "ci" host to 
the existing zone file:


 $ORIGIN cityname.or.us
 @   SOA   ns1.tigertech.net. a.tigertech.net. ( 1 2 3 4 5 )
 @   MX 0  mx.tigertech.net.
 @   A 192.0.2.44
 @   (SPF and DKIM records omitted for brevity)
 ci  MX 0  mx.tigertech.net.
 ci  A 192.0.2.44
 ci  (SPF and DKIM records omitted for brevity)

This also worked fine until recently. But now, messages sent from 
"addr...@ci.cityname.or.us" to AOL or Yahoo get deferred, and eventually 
rejected, with the error above: AOL/Yahoo wants an SOA record to exist 
for "ci.cityname.or.us".


This is new behavior; our logs show the first occurrence of this error 
on April 19, and the first mention of it I can find on the Internet is 
Steve Atkins' Word to the Wise in June: 
.


This is not trivial to fix from a DNS standpoint. You can't just add a 
second SOA record to the zone; the only solution is to split it into two 
separate zones, like this:


First zone:

 $ORIGIN cityname.or.us
 @   SOA   ns1.tigertech.net. a.tigertech.net. ( 1 2 3 4 5 )
 @   MX 0  mx.tigertech.net.
 @   A 192.0.2.44
 @   (SPF and DKIM records omitted for brevity)

Second zone:

 $ORIGIN ci.cityname.or.us
 @   SOA   ns1.tigertech.net. a.tigertech.net. ( 1 2 3 4 5 )
 @   MX 0  mx.tigertech.net.
 @   A 192.0.2.44
 @   (SPF and DKIM records omitted for brevity)

However, many automatic DNS management systems will not support 
splitting a "domain name" into two zones in this manner.


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

Re: [mailop] Guide for setting up a mail server ?

[Jaroslaw Rafa via mailop]

Dnia 12.07.2023 o godz. 13:58:21 Grant Taylor via mailop pisze:
> 
> IMHO, some -- but not all -- that choose not to publish any
> information to make the recipient's lives any easier are somewhat
> choosing to say "I don't care, I'm not going to lift a finger, and
> you must do all the work, even if it's ten times the work compared
> to if I had given you the smallest amount of data."  --  I try to be
> a better net'itizen than that.  A few people / organizations have
> very specific reasons for not publishing information.

I would say otherwise.

A few people / organizations DO have reason to publish SPF/DKIM/DMARC. These
are the ones who send transactional mail. These - when impersonated - could
cause harm to recipients by eg. redirecting them to a malicious website. 
Eg. said delivery companies, online stores, banks etc.

Most of regular consumer email users don't have any reason for this. As Bill
Cole, whom I was replying to, wrote - nobody would try to impersonate you or
me in a phishing campaign for financial gain, because there won't be any.

If I receive mail from an unknown account on Gmail, what does the "pass"
result of SPF/DKIM/DMARC check actually tell me? What benefit gives me the
fact that the message actually does come from Gmail, if Gmail has millions
of users, unknown (but significant) percentage of them being malicious?

On the other hand, if I receive a message from someone I know, I can usually
recognize if it's actually written by that person or someone is trying to
impersonate him/her. The style of writing, relevance to actual events that
we are both concerned about and behavioral patterns (the time when the email
is sent, the correlation between topic and length of the message etc.) are
factors that we all intuitively, subconsciously take into account and are
able to recognize a forgery quite well.

So my opinion is that consumer-oriented email services, especially the big
ones, have in fact little reason to publish SPF/DKIM/DMARC. On the contrary,
corporate domains that are used specifically to send transactional email
have a big reason to do it.

As far as I remember, that was how these characteristics were initially
thought of. Only later the "email oligarchs" forced the attitude that they
should be quasi-mandatory for all.

And to return to the topic, my initial message was not about *not
publishing* SPF/DKIM/DMARC, but about *not checking* them on *incoming*
mail. I still say - I don't do it because I don't need it. I don't remember
a single phishing incident that wasn't at the same time an obvious and
blatant spam, easy to catch by antispam filters. And referring to your
comparison to "800 lb gorilla", if my "800 lb gorilla" does the job good
enough and causes no issues with potential CPU overload on my server, there
is absolutely no need for me to introduce additional "monkeys" that do
(partially) the same job.
-- 
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] Guide for setting up a mail server ?

[Grant Taylor via mailop]

On 7/12/23 9:28 AM, Jaroslaw Rafa via mailop wrote:
Despite I said that SPF/DKIM/DMARC adds little to security, I would 
disagree with what you write here.


The problem is for recipients, not for senders.


I'd argue that almost all SMTP shortcomings are on the receiving end, 
not the sending end.


Assume someone receives a forged mail claiming to be from a delivery 
company (like DHL or similar) saying "Your package cannot be 
delivered, because additional delivery charge of 1$ is required, 
please go here to pay: ".


Detecting (some large subset of) spoofed senders is the primary use I 
see for SPF.


The primary use case I see is spoofed $ADMINISTRATOR from $YOUR_DOMAIN 
saying that your password is expiring and needs to be reset or that you 
have a quarantined message please check it.


Even if one in 1000 people who receive it logs in to the fake 
payment gateway - and in turn will have their online banking 
credentials intercepted and their money stolen - it is a HUGE damage 
if they send this phish to millions of people.


Agreed.

The same type of attack can be performed by impersonating basically 
any company that sells something online, because the key point here 
is to direct recipients to the fake payment gateway, which allows the 
attacker to steal their money ("their" == recipients, not 
impersonated company).


That's one of the key attacks.  Another is to harvest email credentials 
to be used for other campaigns.


Theoretically SPF/DKIM/DMARC should protect against it. But this type 
of messages is also very well recognized and filtered by 
antispam/anti-malware software.


I see many examples of it where anti-spam / anti-virus / anti-malware 
don't detect it.


Almost all of those examples could easily be detected with SPF.

It's also enough that the attacker uses own domain that is similar to 
the impersonated one (for example uses dhl-courier.com or 
dhl-poland.com instead of dhl.com; both don't exist as of this 
writing) to pass all SPF/DKIM/DMARC tests (while the 
antispam/anti-malware software should still properly detect and 
filter the message).


I consider that to be a testament to how successful SPF can be such that 
it moved the problem from impersonation attack to a look-alike / homonym 
attack.  As in we caused the spammers to change their tactics because 
what they were doing no longer works.


Also, as I already said, this type of attack is usually carried out 
using SMS messages to mobile phones, not email (at least huge 
majority of phishing campaigns of this type that were reported by 
security-related websites in my country were carried out using SMS). 
 I don't remember any serious phishing incident in recent years that 
was related to email.


As an email administrator I can't do anything about SMS attacks.  But I 
can do something about email attacks.


Maybe this is because of more widespread use of SPF/DKIM/DMARC, but I 
rather suppose this is because much more potential victims can be 
reached via phone than via e-mail, and because it is much harder to 
verify on a phone what website you are logging to. The phishing 
message uses a link shortener (which seems understandable because of 
the limited length of a text message), people just click on that link 
and land on a website that looks just like the real one they are used 
to.


I've had people be annoyed with me that their password manager didn't 
offer to fill their password on the look-alike website only to later 
wish they had not copied and pasted their password after learning that 
they had just compromised themself.


Fuses blowing and circuit breakers tripping can be annoying.  But they 
are doing so for a reason.  Things are trying to keep us safe.  -- 
Don't put a penny in the fuse box and then wonder why you have an 
electrical fire.


I also think that in the realm of filtering methodologies spam / virus 
filtering takes more computing than DMARC filtering, which takes more 
computing than DKIM, which takes more computing than SPF, which takes 
more computing than basic TCP connection filtering.  As such I try to do 
filtering using the fewest computational resources and thus start with 
the simpler things and work up in computational cost; TCP connection 
filtering -> SPF filtering -> DKIM filtering -> DMARC filtering -> spam 
/ AV filtering.  Can SpamAssassin detect something that fails SPF, quite 
likely.  Do I need the 800 lb gorilla that is SpamAssassin when I can 
use the 80 lb monkey that is SPF?  Nope.  I can use the 80 lb monkey 
perfectly fine.


As you say, the problem is for recipients.  So, why force the 
recipient's hand to use an 800 lb gorilla when they could use the 80 lb 
monkey if you simply provide them data to give the 80 lb monkey in the 
form of publish SPF information.


IMHO, some -- but not all -- that choose not to publish any information 
to make the recipient's lives any easier are somewhat choosing to say "I 
don't care, I'm not going to lift a finger, and you must d

Re: [mailop] Please don't Cc: me, use only the list for replies

[Andrew C Aitchison via mailop]

On Wed, 12 Jul 2023, ml+mailop--- via mailop wrote:


On Wed, Jul 12, 2023, Andrew C Aitchison via mailop wrote:


Please could you indicate who you are and,


Why?


Sorry, I meant to ask for a name or an alias.

Why ?
Because I don't believe that "the paranoid curmudgeon from esmtp.org"
is your preferred way for me to think of you and your comments.


if appropriate, who you work for or represent ?


I do not represent anyone but myself. Hence I prefer not to give
out my name because then some people might think that I speak for
"someone".


It is fine for it not to be appropriate to associate your comments
with an organisation.

I don't really see why is is unreasonable for you to use your name in
a personal capacity. I would have hoped that anyone here who
associated that name with an organisation would have the wit /
education / experience / nous to know that if you aren't using an
organisation's name you are not speaking for them.

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

Re: [mailop] SPF +all considered harmful

[Brandon Long via mailop]

Note that SRS usually refers to a specific rewriting scheme, one that never
went beyond a draft
and wasn't all that useful directly.  You can of course use it, but I don't
think the specific implementation
is that useful.  There were people who felt that Gmail should support SRS
or that it already did, and that was
never true nor useful.

Sender rewriting in general, however, has always had pros and cons.   Yes,
Gmail recommended on their forwarding
page support page to not do rewriting, as at the time that was the better
choice for sites that didn't implement sufficient
anti-spam before forwarding.. and of course the challenge of how do users
handle antispam false positives that weren't
forwarded.

Note that Gmail's own forwarding always did sender rewriting.

With Gmail's turn towards "no auth no entry", the balance has shifted to
recommending rewriting.  This is because
email with only SPF auth will fail to forward (even if it had +all).  The
only solution to that is to rewrite the sender and
have that SPF auth.

We should support ARC for this instead, since that's a more "real"
solution, we'll see if that happens.  ARC would provide a simple
way for a receiver to say that they want forwarded mail from this system,
and the rest would just work.

Anyways, the fact that we now recommend sender rewriting doesn't change all
of the original challenges with doing it.  One could probably
write up a list of more complicated suggestion, such as using a separate
domain just for forwarding (and maybe even a separate IP address),
try not to forward spam mail, try to reject spam mail at smtp time, have
your customers also set up pop fetching to fetch the messages that
don't get forwarded... in fact, you could do that even for messages that
gmail refuses to accept the forward for instead of bouncing back
to the original sender.

You could even try only doing sender rewriting for messages which don't
have a valid DKIM signature, though with dkim replay attacks that has its
own issues.
And not rewriting for messages with no authentication at all, so you aren't
used for an auth upgrade attack.

So many considerations for forwarding.

Brandon

On Tue, Jul 11, 2023 at 11:52 AM Grant Taylor via mailop 
wrote:

> On 7/11/23 10:08 AM, Benny Pedersen via mailop wrote:
> > on next hub envelope sender changes, so new spf problem when next hub
> > forwards mails
>
> This behavior is not guaranteed and SHOULD NOT be relied on.  If it
> works, then great!  But don't be surprised if it doesn't work.
>
> I remember Sender Rewriting Scheme being discussed multiple different
> places many different times and the vast majority of people involved in
> them loathed the idea of the envelope from address being changed at one
> or more hops along the way.
>
> For a long time Gmail actively discouraged SRS et al. saying that that
> they would associate the spam nature with the domain used in the changed
> envelope from address, thereby likely associating it with your server
> instead of the original purported source.

My understanding is that Gmail has (finally?) changed sides and now
> agrees that there are times to change the envelope from address, if not
> actually recommending it.
>
> As for Postfix doing this by default, that's a new information to me and
> I consider it highly atypical.
>
> As someone that has gone out of my way to run SRS on emails that I relay
> (but not originate) I agree with the idea.  But I also think that I'm in
> the extreme minority in my belief / support of SRS.  I take some comfort
> in Postfix (purportedly) defaulting to it.  But I still think that I'm
> in the minority and that most forwarding will not modify the smtp
> envelope from.
>
>
>
> Grant. . . .
> ___
> 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] Please don't Cc: me, use only the list for replies

[ml+mailop--- via mailop]

On Wed, Jul 12, 2023, Andrew C Aitchison via mailop wrote:

> Please could you indicate who you are and,

Why?

> if appropriate, who you work for or represent ?

I do not represent anyone but myself. Hence I prefer not to give
out my name because then some people might think that I speak for
"someone".

-- 
Please don't Cc: me, use only the list for replies, even if the
mailing list software screws up the Reply-To header.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Please don't Cc: me, use only the list for replies

[Andrew C Aitchison via mailop]

Please don't Cc: me, use only the list for replies, even
if the mailing list software screws up the Reply-To header.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop


Please could you indicate who you are and,
if appropriate, who you work for or represent ?

Thanks,

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

Re: [mailop] No MX but A: broken MTA(s)

[Mike Hillyer via mailop]

My associates and I are building a new Open-Source sending MTA 
(https://github.com/KumoCorp/kumomta) and that's our interpretation of the RFC 
as well, so we will fall back to the A record if there is no MX record returned.

Mike

-Original Message-
From: mailop  On Behalf Of Michael Orlitzky via 
mailop
Sent: Tuesday, July 11, 2023 3:45 PM
To: mailop@mailop.org
Subject: Re: [mailop] No MX but A: broken MTA(s)

On Tue, 2023-07-11 at 13:36 -0500, Grant Taylor via mailop wrote:
> 
> However, I don't see any mention of a-record fallback in RFC 5321.  -- 
> I didn't chase any updates.  --  I do see four occurances of "fall" in 
> the document, three of which are fall( )back and all three have to do 
> with something other than MX records vs a-records.
> 
> As such, I'd question the veracity of current SMTP needing to support 
> a-record fallback.


5.1.  Locating the Target Host

Once an SMTP client lexically identifies a domain to which mail will be 
delivered for processing (as described in Sections 2.3.5 and 3.6), a DNS lookup 
MUST be performed to resolve the domain name... The lookup first attempts to 
locate an MX record associated with the name... If an empty list of MXs is 
returned, the address is treated as if it was associated with an implicit MX 
RR, with a preference of 0, pointing to that host.

___
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] No MX but A: broken MTA(s)

[ml+mailop--- via mailop]

On Wed, Jul 12, 2023, Grant Taylor via mailop wrote:

> with Sendmail) send a test message to my user at the test domain. That
> didn't work.  I think that Sendmail in the MSA role rejected things out of

Sorry, but "didn't work" is a completely useless problem description.
Provide real data and real error messages -- that is, a reproducible
case.

> hand about the destination not having an MX record.

No, it doesn't.

-- 
Please don't Cc: me, use only the list for replies, even if the
mailing list software screws up the Reply-To header.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] No MX but A: broken MTA(s)

[Slavko via mailop]

Dňa 12. júla 2023 13:34:42 UTC používateľ Grant Taylor via mailop 
 napísal:

>I then tried to have my primary client using my primary email system (VPS with 
>Sendmail) send a test message to my user at the test domain. That didn't work. 
> I think that Sendmail in the MSA role rejected things out of hand about the 
>destination not having an MX record.
>
>I then tried to have `mail` behind Postfix on a different system send a 
>message to my user at the test domain.  That too failed.  But I don't remember 
>why.

I just tried it with exim (4.94.2) MSA with my smarthost primary name
as address's domain (no MX, only A/) and it works. Of course,
my MSA delivers all nonlocal domains to that smarthost, but before
that it verifies target host (domain) by "normal" SMTP way.

I check debug output of that verify and i see in it attempt to get
MX (nodata), followed by A &  lookups (success) and finally
accept (verify) domain...

I am not familiar with sendmail nor postfix, but perhaps it is
disabled by default (or by you).

regards


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

Re: [mailop] Guide for setting up a mail server ?

[Grant Taylor via mailop]

On 7/12/23 4:11 AM, Slavko via mailop wrote:

BTW, my English is not best, don't take me word by word, please...


I don't think I've had any more trouble understanding you / your use of 
English as an additional language than I have had with others who use 
English as their primary language.  Different uses of meanings of words 
happens within languages too.


Perhaps that was goal, but if so, then i much more like the language 
eg. of RFC5321: ...something "is out of scope of this document".


That works for me.


The only problem here is, that some sites/tools doesn't respects
that broken signarure have to be treated as no signature. But that is
not DKIM's mistake.


I consider / classify that as a problem with a given site's use or 
configuration of DKIM not a problem with DKIM itself.


Individual DKIM installations and DKIM in general can cause problems. 
But the former is much more localized to the specific installation while 
the latter tends to be common across multiple installations.


What is not clear, at least from my point of view, is p=none policy. 
RFC mention it as way to not enforce any policy, but receive

reports.

But what then if DMARC's p=none, no DKIM and SPF fails? Have to be 
applied SPF result or have to be applied none policy?


In my opinion, if a domain's DMARC has a p=none, then you don't filter 
on  DMARC.  But you still independently apply your site's local SPF 
filtering policy preferably following the sending domain's stated SPF 
wishes.  The only thing that you would do with DMARC is send the 
notification of the result.


It is not about which action have i to choose. I wonder what one 
can/have to expect from other sides... Yes i know, their servers,

their rules, thus one can expect relative anything. But no one can
expect anything even on RFC compliant targets...


I think that we should safely expect sites to be largely RFC, or BCP, 
compliant.  I consider that to be the middle of the road and for people 
to stay on their side of said road.



BTW, i apply pure SPF (+ DKIM) in case of DMARC's p=none.


1)  I would expect you to apply SPF independently of DKIM and DMARC if 
the sending domain publishes SPF records.


2)  I would expect you to apply DKIM independently of SPF and DMARC if 
the message has DKIM headers and the sending domain publishes DKIM 
information.


3)  I would expect you to apply DMARC using the aforementioned SPF and / 
or DKIM results if the sending domain publishes DMARC information.


A DMARC policy of none simply elides that 3rd step to me.


Of course, i do my best effort to be as interoperable as i can/know.
I consider that as crucial in mixed environment, as Internet is.


Perhaps ISP was not right abbreviation, sorry for that. I meant email
provider, but i want to avoid ESP abbreviation as it is often used
with conjunction of mass mail here.


I think that ISP and ESP are both correct.  ISP is probably the older 
answer with ESP being the newer answer.


As with all things (Internet related) some are abused or used for things 
we don't like and they can earn an unpleasant meaning.  But I believe 
that Email Service Provider is exactly that, a company that provides 
email service.  What that email service is used for it independent of 
the fact that it is providing email service.


Yes, there are some very questionable / shady ESPs.  But there are still 
many good ESPs.



IMO we basically agree, that plain text connection over public net
have to be secured. I would consider setting VPN for mail only as too
mutch effort, especially for regular users.


I absolutely agree that using some form of encryption is strongly 
recommended and that not using encryption is ill advised.



Sure, there are cases when encryption is not needed, eg. i don't
encrypt communication to 127.0.0.0/8 and ::1, nor over LXC internal
bridge. But my original point was about connections over public and
semi-public networks.

But then nowadays best practices have to mention it.


Yes, encryption of some form is very much so a SHOULD in RFC speak.


But IMO in case of foreign services here is another mean: one cannot
expect, that it will be provided.


That surprises me.

Perhaps other parts of the world have been using TLS, either implicit or 
explicit via STARTTLS, for so long that they are now no longer offering 
service without TLS.


My experience has been that unencrypted connections are still offered in 
the areas where I'm interacting.  Usually unencrypted will work close to 
the service (as in connected to the ISP's network) but may not work 
further away.


I still people using really old configurations without TLS and ISPs not 
choosing TLS when helping customers set up new systems.


In some ways, TLS has been viewed as "oh, you're one of the people that 
want to be really secure", let me get the documents.


The notable exceptions that I've seen are the email oligarchs, some of 
whom tend to be charging full speed ahead and dragging the rest of us 
with 

Re: [mailop] Guide for setting up a mail server ?

[Jaroslaw Rafa via mailop]

Dnia 12.07.2023 o godz. 08:53:16 Bill Cole via mailop pisze:
> For the overwhelming majority of sending systems, the only internal
> security benefit to implementing SPF/DKIM/DMARC is to make
> impersonation of local users by outsiders for the purpose of fraud
> (so-called "BEC") much harder.
> 
> For most sending domains, targeted forgery to the world at large is
> a non-problem. No one is out there impersonating you or me in email
> to random strangers for financial gain. Most businesses do not have
> widespread 'brand value' that can be stolen by random broadcast
> forgery.

Despite I said that SPF/DKIM/DMARC adds little to security, I would disagree
with what you write here.

The problem is for recipients, not for senders.

Assume someone receives a forged mail claiming to be from a delivery company
(like DHL or similar) saying "Your package cannot be delivered, because
additional delivery charge of 1$ is required, please go here to pay: ".

Even if one in 1000 people who receive it logs in to the fake payment
gateway - and in turn will have their online banking credentials intercepted
and their money stolen - it is a HUGE damage if they send this phish to
millions of people.

The same type of attack can be performed by impersonating basically any
company that sells something online, because the key point here is to direct
recipients to the fake payment gateway, which allows the attacker to steal
their money ("their" == recipients, not impersonated company).

Theoretically SPF/DKIM/DMARC should protect against it. But this type of
messages is also very well recognized and filtered by antispam/anti-malware
software.

It's also enough that the attacker uses own domain that is similar to the
impersonated one (for example uses dhl-courier.com or dhl-poland.com instead
of dhl.com; both don't exist as of this writing) to pass all SPF/DKIM/DMARC
tests (while the antispam/anti-malware software should still properly detect
and filter the message).

Also, as I already said, this type of attack is usually carried out using
SMS messages to mobile phones, not email (at least huge majority of phishing
campaigns of this type that were reported by security-related websites in my
country were carried out using SMS). I don't remember any serious phishing
incident in recent years that was related to email.

Maybe this is because of more widespread use of SPF/DKIM/DMARC, but I rather
suppose this is because much more potential victims can be reached via phone
than via e-mail, and because it is much harder to verify on a phone what
website you are logging to. The phishing message uses a link shortener
(which seems understandable because of the limited length of a text
message), people just click on that link and land on a website that looks
just like the real one they are used to.
-- 
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

[mailop] Barracuda contact

[Florent Destors via mailop]

Hi all

I am looking for a Barracuda contact.
If there's someone who could reach out to me or put me in connection, I
would appreciate

Thank you

Florent Destors

Deliverability Consultant Selligent

florent.dest...@meetmarigold.com |  +33 (0)6 13 20 61 16 |  meetmarigold.com
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Guide for setting up a mail server ?

[Taavi Eomäe via mailop]

On 12/07/2023 15:53, Bill Cole via mailop wrote:
For most sending domains, targeted forgery to the world at large is a 
non-problem. No one is out there impersonating you or me in email to 
random strangers for financial gain.


That is simply not true. For the past two years we have been seeing an 
ongoing onslaught of malicious actors "forging" four-letter .com 
domains. There have been actual cases of the owners of those domains 
wondering why they're ending up in spam. The answer is simple - sorry, 
your letters are not differentiable enough from spam. That's just one 
example of many.


You're never too small to become random collateral. I'd say you're never 
so small to be impersonated either, but I can't share examples of that.


Mechanisms for general public authentication of email from strangers 
exist for the primary benefit of big senders, their customers, and 
their prospective customers who need to know that their spam is 
authentic. 


So yeah, that is absolutely false.



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

Re: [mailop] No MX but A: broken MTA(s)

[Grant Taylor via mailop]

On 7/12/23 1:02 AM, ml+mailop--- via mailop wrote:
Maybe you can explain how you tested it and which software (MTA?) 
was used?


Sure.

I stood up a VPS and configured Sendmail as I have done for 20+ years.

I created a (sub)domain-name -- in a different domain than my main 
domain name -- that resolved to said VPS but no corresponding MX record.


I then tried to have my primary client using my primary email system 
(VPS with Sendmail) send a test message to my user at the test domain. 
That didn't work.  I think that Sendmail in the MSA role rejected things 
out of hand about the destination not having an MX record.


I then tried to have `mail` behind Postfix on a different system send a 
message to my user at the test domain.  That too failed.  But I don't 
remember why.


Neither of the two failures seemed to be related to anything other than 
the lack of MX for the test domain.  I say this because as soon as I 
added an MX record and re-tested, both of the above tests worked.


It has been many months since I last did this test.  But that's what I 
remember both with the most recent test and similar results with 
previous tests.


I tend to re-test this every 2-5 year because it comes up in discussion 
and I'd like to have first hand experience with sending and receiving in 
such a configuration.  I have third, if not second, hand reports of this 
working for others.




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

Re: [mailop] Guide for setting up a mail server ?

[Bill Cole via mailop]

On 2023-07-12 at 05:46:47 UTC-0400 (Wed, 12 Jul 2023 11:46:47 +0200)
Jaroslaw Rafa via mailop 
is rumored to have said:

Exactly, because from my experience SPF, DKIM and DMARC bring very 
little

(if anything at all) to security. I


TRUTH.

For the overwhelming majority of sending systems, the only internal 
security benefit to implementing SPF/DKIM/DMARC is to make impersonation 
of local users by outsiders for the purpose of fraud (so-called "BEC") 
much harder.


For most sending domains, targeted forgery to the world at large is a 
non-problem. No one is out there impersonating you or me in email to 
random strangers for financial gain. Most businesses do not have 
widespread 'brand value' that can be stolen by random broadcast forgery. 
Mechanisms for general public authentication of email from strangers 
exist for the primary benefit of big senders, their customers, and their 
prospective customers who need to know that their spam is authentic.



--
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] Guide for setting up a mail server ?

[Jaroslaw Rafa via mailop]

Dnia 11.07.2023 o godz. 18:47:03 Grant Taylor via mailop pisze:
> On 7/11/23 4:20 PM, Jaroslaw Rafa via mailop wrote:
> >For start, I suggest to implement SPF, DKIM and DMARC only for
> >outgoing mail, and in fact only to satisfy Google's requirement that
> >these should be in place. Don't bother checking them on incoming
> >mail. (It's actually how I do it).
> 
> I am extremely surprised to see that recommendation, especially here
> on the mailop mailing list.
> 
> That seems very much like "checklist compliance" and not actual
> security that said checklist is evaluating.

Exactly, because from my experience SPF, DKIM and DMARC bring very little
(if anything at all) to security. I have written above - this is only to
satisfy Google's requirements. Stupid requirements, IMHO, but as you said -
their server, their rules, if I want to send mail to them I need to have
(outgoing) SPF, DKIM and DMARC set up. That's the *only* reason why I had
set them up at all.

> I'm actually more worried about phishing than I am spam.  Spam is an
> annoyance but much less dangerous than phishing.  Phishing can cost
> people a LOT.

I had (and still have) no problems whatsoever with phishing without having
to check SPF, DKIM or DMARC. I simply don't need them. Phishing messages
are already caught by antispam filters - I look from time to time into what
my antispam filters have caught and I see a few phishing messages there. 
They are usually so obviously blatant that I wonder how anybody could fall
victim to them - like those famous "I have recorded you masturbating to porn
websites, send me money" emails.

In fact, I receive more phishing via text messages on my phone than I do on
my email. The SMS phishing is actually far more dangerous, because on a
phone you have very little possibility to check if a message is genuine
(there are no headers to look into etc.), and usually shortened links are
used in the message, so you don't know where the link points to. But if you
use some reasoning, those phishing SMS messages also look little probable to
be authentic.

Email phishing is from my point of view a practically nonexistent thing. So
why bothering configuring tools that are theoretically meant to protect
against it (but in my opinion are actually not helpful at all), if they
wouldn't bring any benefit?

Of course YMMV, as I said. I have never experienced phishing as an actual
problem.
-- 
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] Guide for setting up a mail server ?

[Slavko via mailop]

Dňa 11. júla 2023 18:23:45 UTC používateľ Grant Taylor via mailop
 napísal:

BTW, my English is not best, don't take me word by word, please...

>I suspect that one of the things that makes email harder is that it
>encompasses many other interrelated and interdependent things.  So if
>you're starting from zero there is a lot to learn.

Yes.

>I suspect that some of that was on purpose as to not dictate what
>recipients should do.  After all, your server, your rules.

Perhaps that was goal, but if so, then i much more like the language
eg. of RFC5321: ...something "is out of scope of this document".

>I think SPF itself is relatively straightforward.

Yes, it is.

>IMHO DKIM is slightly more complex:

More complex to implement, but othervise straightforward.

The only problem here is, that some sites/tools doesn't respects that
broken signarure have to be treated as no signature. But that is not
DKIM's mistake.

>DMARC is more complicated yet in what it checks.

Its check & implementation is straightforward too.

What is not clear, at least from my point of view, is p=none policy.
RFC mention it as way to not enforce any policy, but receive reports.

But what then if DMARC's p=none, no DKIM and SPF fails? Have to be
applied SPF result or have to be applied none policy?

It is not about which action have i to choose. I wonder what one
can/have to expect from other sides... Yes i know, their servers, their
rules, thus one can expect relative anything. But no one can expect
anything even on RFC compliant targets...

BTW, i apply pure SPF (+ DKIM) in case of DMARC's p=none.

> Of course this is predicated on you wanting to utilize said
> specification in an interoperable way.

Of course, i do my best effort to be as interoperable as i can/know. I
consider that as crucial in mixed environment, as Internet is.

>Using your ISP as a smart host is, or was, a good way to do this for
>many people for many years.  Now, things like SPF make this a little
>bit more difficult.

Perhaps ISP was not right abbreviation, sorry for that. I meant
email provider, but i want to avoid ESP abbreviation as it is often
used with conjunction of mass mail here.

>Can we agree to disagree?

IMO we basically agree, that plain text connection over public
net have to be secured. I would consider setting VPN for mail
only as too mutch effort, especially for regular users.

>So again, TLS is not strictly required for email to function.

Sure, there are cases when encryption is not needed, eg. i
don't encrypt communication to 127.0.0.0/8 and ::1, nor
over LXC internal bridge. But my original point was about
connections over public and semi-public networks.

But then nowadays best practices have to mention it.

>The four meanings that Meriam-Webster provides for deprecation all
>imply that something is depreferenced, desire to avoid, should not
>use. However none of them mean that it is non-functional.

But IMO in case of foreign services here is another mean: one
cannot expect, that it will be provided.

>Again, legacy is not the same as non-functional.

I understand legacy as something to avoid if possible and/or
expect, that it can be not provided by remote side.

>Questionable is not the same as non-functional.

Sure. By questionable i meant, that i often read about LAN as
about secure environment. Of course, it is more secure than
public net. But eg. in job i didn't consider our LAN as secure
network, for warious reasons.

>All three of your terms; deprecated, legacy, and questionable have
>significantly more to do with if they would be chosen to be used today
>and effectively nothing to do with if they function or not.

We are still talking about "best practices", right? My words
was not meant as to be included in it, but about ponting to
what have to be take into account, when writing that practices.

>The protocols themselves still function and do the job that they were
>designed to do.

Sure, SMTP, IMAP and/or POP (and many other application layer
protocols) will work independly of that if its transport channel is
secured or not. That is not the question. The question is who
can see communication content and where the clients will be
connected to.

AFAIK, the TLS was designed to work independently on upper layer
protocols.

>Sadly, I find that MTA-MTA use of STARTTLS is not nearly what I would
>hope that it is.

Can you please elaborate more about this?

>> Please, how this DKIM certificate looks as? Where its format is
>> defined?
>
>I'd have to go look things up, but I don't think that the certificate
>format is defined anywhere.  Rather DKIM focuses on the permutations
>(read: math) applied to selected part of the messages.  Howe the
>keying material is stored for that on a given server is implementation
>dependent.

My pont was, that DKIM uses keys pair. The certificate, as known eg. in
TLS, is basically public key + couple additional data... AFAIK these
additional data are not used in DKIM, just keys.

>SMTP, POP3, and IMAP all 

Re: [mailop] key exchange parameters: ECDHE, DHE, RFC 7919

[Bastian Blank via mailop]

Hi

On Wed, Jul 12, 2023 at 01:00:43AM +0300, Taavi Eomäe via mailop wrote:
> On 11/07/2023 20:43, Bastian Blank via mailop wrote:
> > Given that this host only reacts on port 25 but not on port 587, I
> > assume this is MX.
> Ideally one would offer implicit TLS on port 465 as well (RFC8314).

But this RFC talks about submission of e-mail, exactly not what this
thread is about.

> > You are talking about MX, which is unauthenticated in the absence of DANE.
> There's also MTA-STS, which doesn't rely on DNSSEC and introduce operational
> complexity.

This, the same way as DANE, asks the client to do authentication.  So it
is not included in my statement.  And in that case the client enforces
more strict rules normally.

Bastian

-- 
We Klingons believe as you do -- the sick should die.  Only the strong
should live.
-- Kras, "Friday's Child", stardate 3497.2
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop