On 07/18/2017 10:02 AM, Mark Jeftovic wrote:
Value add
Are you looking to have the appliance handle all email and only filter
some of it (value add subscribers)?
Or will you be doing something in front of the appliance to sort
value-add and non-value-add?
--
Grant. . . .
unix || die
On 07/25/2017 09:14 AM, Vladimir Dubrovin via mailop wrote:
STARTTLS is opportunistic and doesn't protect against active
Man-in-the-Middle. In case of TLS problems it falls back to plain text.
STARTTLS is opportunistic, but MTAs can be configured to require
protected channels and to refuse ema
On 07/27/2017 11:44 AM, Dave Warren wrote:
I've never understood why this is a special challenge in the SMTP world,
it's generally a solved problem for HTTPS, XMPP, and various other
protocols.
It's my understanding that the problem has to do with the (lack of)
people involved in the transact
On 07/28/2017 06:58 AM, Michael Orlitzky wrote:
If someone connects to me and I don't like his CA, he
can fall back to plain text and I have to allow it (because of the
bajillions of people who don't do TLS over SMTP at all).
I disagree. You do have the choice to not accept messages over an
u
On 07/28/2017 02:10 AM, Vittorio Bertola wrote:
On the Web, instead, users do want to know which company is actually
running the website that they are visiting, and not just that they are
really connecting to that hostname, so CAs offer additional value in
respect to DANE.
Full STOP!
I disag
On 07/28/2017 03:19 PM, Brandon Long via mailop wrote:
> If someone connects to you, they don't send you a cert unless you're
> dealing with client certs, and I don't think DANE covers that at all,
> though I haven't read through it completely.
It's my understanding that DANE covers client certs
On 08/31/2017 09:32 AM, Luis E. Muñoz via mailop wrote:
I believe they misspelled "v=spf1 -all"
Why would a spammer purposely use a SPF record that states that no email
is sent?
That seems like it would be the exact opposite of the very thing they
want to do.
Is this some sort of techniqu
On 09/11/2017 06:22 PM, Luis E. Muñoz via mailop wrote:
I'm going through RFC-5821 and none of the codes mentioned there seem to
be a perfect match to "hitting a rate limit for an authenticated user"
in my submission servers.
Are you wanting to rate limit incoming email being delivered to loca
On 09/11/2017 06:52 PM, Luis E. Muñoz via mailop wrote:
Indeed, I would like the sender to know right away. In my use case I
intend to place this on a MSA, so I would expect to see few if any mail
servers -- but in any event it's good to consider this case.
I agree that MUAs will ideally show
On 09/12/2017 03:36 PM, Brandon Long via mailop wrote:
Thinking about this, it makes sense. It's not a short term temporary
condition, it's something that could take hours to resolve, and having
your mail sit in your outbox for who knows how long retrying, and maybe
the user doesn't notice and
On 09/13/2017 02:25 AM, Paul Smith wrote:
This changes if you have another MSA submitting to yours. We have this
here when we have customers running our mail server software on their
networks and send through our relay service. (They can't have their
local mail server send direct because they d
On 09/25/2017 01:41 PM, Miles Fidelman wrote:
Thanks to all (and your responses motivated me to go reread the IMAP spec.)
;-)
Now I have to figure out how things got screwed up (and if there's any
way to recover - sigh...).
I think UW-IMAP uses mbox. Which probably means that the mbox file
On 09/28/2017 04:38 PM, Luke Martinez via mailop wrote:
I'm a little confused as to what is going on here.
This is probably one of the weirder message traces I've seen.
The message gets delivered to a tagged gmail address, and then it
somehow ends up getting forwarded from a hetzner IP
(2a01
On Sep 28, 2017, at 8:25 PM, Suresh Ramasubramanian wrote:
> Bounce feature in pine / elm / mutt
Wouldn't a bounce to back to the original sender?
Or are you suggesting that the message is being redirected using similar
technology?
> The strredwolf guy is an antispammer who used to be regular
On 11/02/2017 08:53 AM, Alexander Zeh wrote:
I dare to disagree with your opinion that the sender is to blame.
I don't think that the sender is responsible for what receivers do with
messages.
I *do* think that it is /prudent/ for the sender to be aware of what
recipients /might/ do with th
On 11/02/2017 12:49 PM, Michael Peddemors wrote:
Ouch, I can name a hundred reasons to..
Sorry, let me clarify.
I see no reason to reject messages at SMTP time just because you might
choose not to display all of the message in the default view, yet make
it available in a full message view.
On 11/14/2017 06:03 PM, Mark Milhollan wrote:
satellite can be terrible and links into disaster areas can
be worse, not even counting personal or overloaded servers
Why are obvious problem links significantly influencing current standards?
If I were to stand up a link across such a hostile con
On 11/22/2017 06:47 PM, Brandon Long via mailop wrote:
I never liked the design choice which said permission failure had to
look like nonexistence,
Is this a reference to the mentality of needing to say "username or
password" instead of "password" in an attempt to not confirm that a
"username
On 12/07/2017 06:50 AM, David Hofstee wrote:
Can people here share their experience (or spamfilter
configuration) with differing 5322.>From and 5322.Reply-To domains in
larger volumes of email? Is it a problem, if so, where? If it is a
problem, are there requirements so that legitimate email is
On 12/14/2017 03:28 PM, Brandon Long via mailop wrote:
My point is that -all is policy, and most people ignore the policy
portions of SPF because it completely fails a lot of forwarding cases.
Every postmaster (or organization behind them) has the prerogative to
run their mail server(s) the wa
On 12/14/2017 05:29 PM, st...@greengecko.co.nz wrote:
given just how hard it is to ensure your SPF is followed in these days
of mobile devices I don't think you should
I'll argue that mobile devices should be connecting to MSAs that are
under full control and configured to work within SPF (et
On 12/14/2017 06:23 PM, Steve Atkins wrote:
If you want to argue more loudly that you *do* understand what it means
you could publish a matching DMARC record with p=discard. Doing that would
tell recipient ISPs that either you've actually done appropriate analysis
of your mail stream, you under
On 01/02/2018 01:18 AM, Benoit Panizzon wrote:
I seem to observe, that more servers have started rejecting email because
of 'helo / hostname' mismatch.
Please clarify what you're talking about matching. There are three
names that come to mind: SMTP's HELO / EHLO name, the A / (/
CNAME)
On 01/16/2018 09:26 AM, John Levine wrote:
Several of the mailing lists I'm on are plagued with mail purporting to
be from subscribers but actually from a thing called BitBounce.
Oh my. The fact that a fancy challenge response spam filter that is
hosted by a 3rd party is interacting with mail
On 01/16/2018 03:09 PM, John R Levine wrote:
It's so obviously doomed to fail that I can't figure out what their
angle is.
I'm guessing that BitBounce will get a nominal portion of the payments
that flow through them.
If that covers their operating cost, great.
I will be surprised if it act
On 01/16/2018 09:26 AM, John Levine wrote:
Several of the mailing lists I'm on are plagued with mail purporting to
be from subscribers but actually from a thing called Bitbounce.
After re-reading that, and some exploration in BitBounce, I think that
you should consider such messages purportedl
On 02/23/2018 12:28 PM, David Carriger wrote:
With the exception of Rutgers, these are all hosted on Office 365. Once
the mail has delivered, I'm seeing all of the links inside the email hit
within a span of time varying between 1-10 seconds. For example, here's
an unsubscribe in our database f
On 03/06/2018 06:56 PM, Dave Lugo wrote:
I completely agree. So, unsure how gmail should handle that. Be more
lenient on open rates?
I think Dave may be onto something about the absence of negative
information.
Could the bank transition some or all of that traffic to SMS, where it
might b
On 04/18/2018 05:49 PM, Al Iverson wrote:
If you're downloading all your O365 mail and pulling the IP out of that
header, then it's always going to be in the same format and dealing with
it is trivial. Beyond that, when would it be safe to trust this received
header, anyway? Unless it's the mos
On 05/09/2018 12:19 PM, Steve Atkins wrote:
take it to the spam or messaging abuse focused lists
Can I get some pointers to / names of such lists?
I'd like to make sure I'm not missing something.
Thanks in advance.
--
Grant. . . .
unix || die
smime.p7s
Description: S/MIME Cryptographic
On 05/25/2018 04:32 AM, Leo Gaspard via mailop wrote:
Just for the record, OpenSMTPD supports queue encryption with the `queue
encryption` option.
Nice.
I'll have to look into that, particularly how it does things. I'm
assuming that it encrypts / decrypts individual files / message stores.
On 05/25/2018 04:49 AM, Paul Smith wrote:
If the software can decrypt its own encrypted data automatically, then
the decryption key/method is on the PC, so not going to stop a
determined attacker.
I don't know if this exists or not, but I could see how files
(independently of disk encryption)
On 06/09/2018 09:32 AM, Andrew C Aitchison wrote:
If a domain has no MX record, do all servers deliver to an record,
as required by (at least) RFC3974, or do some email systems ignore
domains with no MX and no A record ?
My personal stance has been "Don't be surprised if the lack of an MX
On 06/10/2018 03:26 PM, Al Iverson via mailop wrote:
I cry a little inside every time I see a null MX, think of the lost
opportunity to be handling it as a spamtrap domain instead.
~chuckle~
Fair enough.
I also view it as an opportunity to accidentally leak email that ends up
being feed into
On 07/11/2018 08:37 AM, Michael Peddemors wrote:
But it has got to the point that our guys have rules that use the fact
that you are on Linode space, certain behaviors will get you straight to
the permanent reject really fast, with less 'forgiveness'.
As a small time / personal operator that u
On 07/11/2018 12:08 PM, Grant Taylor via mailop wrote:
Ya. I'm dealing with that on a shared /64 for IPv6 with one mailing
list that I subscribe to and have problems replying. Fortunately IPv4
gets through so I block IPv6 to them. It's an ugly hack but it allows
me to reply to t
On 07/19/2018 11:18 PM, Autumn Tyr-Salvia wrote:
Hello Email Folks,
Hi Autumn,
I know signing the From: field is required by spec, but I think
everything else is technically optional. For those of you who have been
in the position of choosing which headers to sign and which not to,
would yo
On 07/24/2018 06:02 PM, Michael Peddemors wrote:
Keep pushing, and of course in the end customers will vote with their
wallets.. AS long as we keep seeing outbreaks like..
Do you have any statistics of what the hello name is used by those senders?
I notice that none of them seem to resolve to
On 09/21/2018 03:43 PM, Brandon Long via mailop wrote:
After receiving the mail from smtp, we attempt for 3d to deliver to the
user's mailbox, and there are conditions under which it might not
succeed, in which case we'll generate a bounce. I think we're over 99%
in the first attempt when the
On 10/01/2018 03:00 PM, Brandon Long via mailop wrote:
We've typically recommended forwarders to not rewrite the envelope
sender when forwarding for this reason, but that was mostly pointed
at tech folks running their own servers (this page has a section for
procmail https://support.google.com/
On 11/16/2018 12:26 PM, Michael Wise via mailop wrote:
And if the email isn't opened, or there is no show of interest over the
course of the past 3 - 6 months ...
Are you advocating for some sort of per recipient tracking to be used as
a signal to indicate if the email was opened (disposed)?
On 11/27/2018 05:03 PM, Michael Peddemors wrote:
Okay, I get it.. you don't want the customer to reply to your 'Latest
News' blast about your product, but if you ARE going to use
'donotreply@', at least put the proper headers to indicate that ...
Auto-Submitted: auto-generated
X-Auto-Response-
On 12/13/2018 08:44 AM, Benoit Panizzon wrote:
I don't want to be the one explaining to our customer why our system
deleted his email after receiving it.
I would much rather explain why an extra message was put into the spam
folder than explain why we didn't deliver a message.
Content filter
On 01/08/2019 09:55 AM, Benjamin BILLON wrote:
I'd be interested in that too.
As would I.
As I'm not aware of such list, what about just starting it from
scratch? We could put it on Wikipedia or anywhere else where it makes
sense, and where we would have history and versioning.
I'm not opp
On 01/08/2019 11:33 AM, Michael Peddemors wrote:
We have long been planning on a IPv6 MTA registry, where those wanting
to run MTA's on IPv6 could register as a certified operator, eg. a
legitimate party with proper abuse contacts etc..
Okay. I question how large the value is in that.
I say
On 01/08/2019 10:32 AM, John Levine wrote:
A lot of them have been turned into spamtraps after rejecting mail for
a year or so. For obvious reasons, the people using them will not tell
you what they are.
I think there is a significant difference in a list of defunct sending
domains and a lis
On 01/08/2019 12:46 PM, John Levine wrote:
Why would spam trap domains want to say anything?
So that their domain(s) would be ineligible to be listed.
Something as simple as the following would render a sending domain
ineligible.
From: postmaster@domain.eample
Subject: I send email.
On 01/08/2019 01:49 PM, John R Levine wrote:
(I) don't see it as very useful.
Fair.
I'm of the opinion that an RBL is not difficult to set up. To me the
difficult thing is sourcing data to put in it.
I do also want to be sure that if such is done, there is some sanity
around it.
Can I a
On 01/08/2019 02:36 PM, Rob McEwen wrote:
I get offers OFTEN from those who had been blacklisted by invaluement,
where they ask, "Rob, can we pay you to up us set up our system better
so that we won't have the kind of security breaches that caused us to
get blacklisted?" (and then I kindly stat
On 01/09/2019 07:58 AM, John Levine wrote:
Sounds like it'd be more useful to persuade those domains to publish a
null MX. Then everyone's mail to them will fail automagically.
Agreed.
However that requires that the domains still be registered and having
DNS service.
Granted, MTAs should r
On 01/09/2019 09:45 AM, John Levine wrote:
Sounds like it'd be more productive to fix the code in the MTA rather
than to invent a band-aid and then try to make the MTA use the band-aid.
Rejecting mail for authoritative NXDOMAIN failure is pretty basic.
I think most of the MTAs (that I've looke
On 3/16/19 11:50 AM, Alessandro Vesely wrote:
The issue with ARC is that it means nothing to small servers which don't
track domain reputation. They can easily add ARC stuff on forwarding,
but won't be able to evaluate incoming chains which may be spoofed.
Hence, small servers will have to lea
On 4/8/19 3:13 PM, Dennis Glatting wrote:
I got tired of the SSH/SMTP attacks from DO and zero effective response
to abuse reports, so I've been slowly adding their net blocks for the
last six months.
Fair enough.
Is there a reason why you're adding them as a onesie twosie manner?
If I were
I overheard a question and ensuing conversation today that I didn't know
the answer to.
Are there any standards around no-reply type addresses? They are
typically used from some sort of CMS (et al.) that sends an email but
does not want a reply.
The back story in this case involved two such
On 4/10/19 8:11 PM, Jay Hennigan wrote:
I hold a very low opinion of any business entity that sends me automated
email and either deliberately chooses to ignore my reply or forces me to
jump through hoops in order to reply via a web form or such.
The use case that has me asking is in some ways
On 4/11/19 6:57 PM, Patrick wrote:
Alternatively, accountability could be increased by marking the From
address as do-not-reply and setting Reply-To with a subaddress,
How does that add accountability?
I feel like it's still subject to address harvesting.
e.g.
b...@example.com -> fi
On 4/11/19 8:26 PM, Patrick wrote:
bob+megac...@example.com is only published to MegaCorp, so any
non-MegaCorp email received at bob+megac...@example.com implies that
MegaCorp has an email privacy issue.
I get the logic. I've done similar for about 15 years.
Filter the old token then issue
On 4/11/19 9:36 PM, Patrick wrote:
It'd be nice to be able to authenticate and send from one address and
*reliably* receive email only at the Reply-To.
One of the problems I have with *no*reply*@, particularly with a
Reply-To:, is 1) I think replies (RFC) SHOULD be accepted /somewhere/
and 2
On 4/14/19 8:40 PM, Eric Tykwinski wrote:
We received something rather strange, basically normal spam but a lot of
attachments, like 10 to 12 jpgs, or sometimes txt attachments.
Seems like a buffer overflow or something that’s not effecting us and I
haven’t heard anything from clients, but just
On 4/27/19 3:54 AM, Simon Lyall wrote:
The below message was bounced by everyone (I assume) in the list whose
address is hosted by gmail.
I would be surprised if it was just Gmail.
Date: Wed, 24 Apr 2019 08:44:58 -0600
From: Brielle Bruns
Subject: Re: [mailop] The utility of spam folders
I
On 4/27/19 11:16 AM, John Levine wrote:
I wouldn't. Gmail has made it quite clear that on their v6 mail
servers they will only accept mail that is SPF or DKIM authenticated.
If you don't authenticate, send to their v4 mail servers. I don't
know anyone else who does that.
Hum.
I suspect tha
On 4/27/19 1:09 PM, Bill Cole wrote:
Yes, because the signature included the Sender and List-* headers,
probably non-existent originally, which mailing lists typically
(including this one) add to messages they relay.
Thus the Sender and List-* headers were oversigned.
Signing the non-existenc
On 4/27/19 11:43 PM, Bill Cole wrote:
I can't say "should" because that's a site-specific/sender-specific choice.
As is the choice to (over)sign headers, even non-existent headers;
List-*, Sender, etc.
It's a thing that could be done with some effort, the right tools, and
properly trained u
On 4/28/19 10:21 AM, Bill Cole via mailop wrote:
Or just set bounce_score_threshold to a sane value?
Doing that simply moves the line. It doesn't actually solve the problem.
It may work for most normal day-to-day sending values. But any time you
have a contentious topic, like this one, come
On 4/28/19 11:35 AM, John Levine via mailop wrote:
Oversigning those headers is silly.
Oversigning may be /silly/. But it's still the sending site's choice.
Let's say you send out a DKIM signed message without Sender and
List-Foo, and then an extremely malicious mailing list grabs your
mess
On 4/28/19 12:38 PM, Chris Adams via mailop wrote:
So should mailing lists reject such messages?
No. Absolutely not.
The DKIM specification states that a failed DKIM-Signature validation
should be treated like a lack of a DKIM-Signature.
I think the list MTA should accept the messages with
On 4/28/19 11:50 PM, Kurt Andersen (b) via mailop wrote:
Mailop either needs to implement ARC (there are solutions for that which
work with Mailman 2 & 3), sign outgoing mail with its own DKIM signatures
(along with header munging), or implement SPF authentication in order
to have authenticatio
On 5/2/19 4:07 AM, Thomas Walter via mailop wrote:
Speculations:
https://news.ycombinator.com/item?id=19391851
Hum.
IMHO openspf.org is (was?) a somewhat important site.
I wonder if there needs to be a community effort to contact him and
recover data to resurrect the site / service.
I wond
On 5/2/19 7:06 AM, Johann Klasek via mailop wrote:
Just from our perspective, SRS works well as far as I can see, at
least with a minor patched srs-socketmapd for our Sendmail environment.
https://jk.kom.tuwien.ac.at/~jklasek/Software/srs-socketmapd/ Because
not all of our e-mail addresses are
On 5/2/19 9:55 AM, Rich Kulawiec via mailop wrote:
In addition: thanks to password re-use practices, which are epidemic,
"giving provider $X a password so that they can POP email from provider
$Y" is semantically equivalent to "giving provider $X passwords to
some/most/all other accounts of oth
On 5/4/19 3:44 AM, Vytis Marciulionis via mailop wrote:
DNS Error: 6443565 DNS type 'mx' lookup of example.com responded
with code NXDOMAIN Domain name not found: example.com
Has anything changed and now we can consider "no MX record" a valid
reason to not deliver messages to that domai
On 5/27/19 4:10 AM, Benoit Panizzon via mailop wrote:
Hi all
Hi,
But we use RT/4 as issue tracking system. If I reply to a case we have
open with them. They do not get my reply, despite our logs showing a
successful delivery to aspmx.l.google.com and no late bounces being
received. We did t
On 6/26/19 6:52 AM, Tobias Matthaeus via mailop wrote:
Hello everybody,
Hi,
The following scenario:
A Freenet user writes an e-mail from bspw us...@freenet.de to
us...@externedomain.de The e-mail address us...@externedomain.de is
again hosted on my mail server and is provided with redirect
On 6/26/19 9:15 AM, John Levine via mailop wrote:
Once again, with free services, sometimes you get what you pay for.
I don't see what the price of the Freenet email service has to do with
anything.
Each and every single organization has the freedom to run their email
infrastructure however
On 7/18/19 4:08 AM, Benoit Panizzon via mailop wrote:
Hi List
Hi,
Unfortunately with emails sent over Gmail, there are no more IP source
before the Google IP Address, so I started wondering if there is any
other way to find an unique source in the Gmail Headers:
I will be quite surprised if
On 8/14/19 12:26 PM, Andy Smith via mailop wrote:
I don't really get how it's harder to see the mail's source since the
person's name is right there in the From header still.
It can come into play when you search for a from address, which will now
be the mailing list instead of the original su
On 8/15/19 11:17 AM, Mark Milhollan via mailop wrote:
perhaps a way can be found for your MUA to help you
It's a complete hack.
But I use procmail to doctor messages as they come into my mailbox. I
mostly add List-Post: header if it doesn't exist and rely on my MUA's
Reply List function.
On 8/19/19 1:45 PM, Marc Goldman via mailop wrote:
Hi Folks,
Hi,
We are rebuilding our entire mailing platform from the ground up and
trying to do everything according to RFCs (or as close as possible).
We are running into an issue where header length is concerned:
https://www.ietf.org/rfc
On 6/28/23 11:07 AM, Chris Truitt via mailop wrote:
The Mimecast spam checking appears to be clicking every link. This has
inadvertently caused an uptick in Unsubscribes.
Aside: Isn't this why the unsubscribe links are encouraged to use /
require a POST so that simple GETs don't accidentally
Dear ${FELLOW_EMAIL_ADMINIATRATOR},
I don't know how to preface this email other than to say -- I believe
the following needs to be said lest we loose even more control of our
email community.
I'm sorry that both 1) I feel that the following needs to be said and 2)
that I'm the one that's sa
On 7/10/23 2:40 PM, Jarland Donnell via mailop wrote:
The problem is, running any blacklist and wanting to constantly speak to
people who are often just confused about how relevant your list even is,
are very often two different things. So there's not anyone to talk to,
at least not from a publ
On 7/11/23 4:18 AM, Jaroslaw Rafa via mailop wrote:
Sadly, you're probably right. It would take someone as universally
trusted (and as trustworthy) as Jon Postel was once, to run such a
service. But there are no people like Jon Postel in decisive
positions anymore...
Yes, I try to find the goo
On 7/11/23 4:26 AM, Jaroslaw Rafa via mailop wrote:
TECHNICALLY, any email (there is no technical difference if it is B2B
or not) requires only a machine that has an A record and a running
MTA.
I'll wager a lunch that A records aren't even required. Maybe not any
name resolution at all. Thi
On 7/11/23 8:15 AM, Bill Cole via mailop wrote:
Surprisingly, A-record fallback works just fine for B2B email.
My experience differs. I've found A-record fallback to work inconsistently.
I think that A-record fallback is dependent on the sending MTA.
No one notices. Or at least no one appear
On 7/11/23 4:54 AM, Slavko via mailop wrote:
If something have to be said, then it have to be said and then
doesn't matter who said it ;-)
Well said.
Nowaydays (especially joung) people tends to feel as experts, when
they setup something first time. Thus, when not used word by word, it
is goo
On 7/11/23 8:29 AM, Bill Cole via mailop wrote:
It is worthwhile to protect the details of a SMTP session on the wire,
beyond simply protecting the contents of email.
Agreed.
+1
E2E tend to only address data and completely ignores metadata which
transport encryption helps.
Grant. . . .
_
On 7/11/23 12:35 PM, Michael Orlitzky via mailop wrote:
Seriously though, it's not a "fallback" in any pejorative sense.
SMTP predates much of DNS, including MX records. It's a fundamental
part of the specification.
I largely agree, especially from a historic point of view.
However, I don't s
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 Rewr
On 7/11/23 2:09 PM, Sebastian Nielsen via mailop wrote:
I think sender adress should be changed.
I think that /forwarding/, as in altering the envelope recipient
address(es), probably should have the envelope sender address changed.
I say /probably/ because I'm sure there are some situations
On 7/11/23 2:45 PM, Michael Orlitzky via mailop wrote:
5.1. Locating the Target Host
Thank you for the pointer Michael.
Today I Learned :-)
Grant. . . .
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
On 7/11/23 2:48 PM, John Levine via mailop wrote:
If your From: domain has neither an A nor an MX, I don't think
you're going to get much mail of any sort delivered.
I believe it's possible for two entities to configure their email
servers to exchange email with each other without the use of DNS
On 7/11/23 3:00 PM, Jarland Donnell via mailop wrote:
Does anyone actually receive mail by their A record in 2023? I'd just
assume break the RFC and save the resources for retrying and eventually
bouncing every email that ends up attempting delivery to an A record.
I have seen a-record fallbac
On 7/11/23 4:31 PM, Jaroslaw Rafa via mailop wrote:
Hm... does this smell a bit X.400 or is it only my impression?
I believe the idea is protocol agnostic.
But I used to see it more in the '90s back when X.400 / OSI was much
more of a thing.
I am quite certain that I've seen this type of B2
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 extrem
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 r
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. Dif
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
On 7/13/23 2:24 AM, Gellner, Oliver via mailop wrote:
The requirement is actually less restrictive as it only requires a
SOA record and not additional A, or MX records in DNS. It is not
necessary that every hostname has a SOA record, that indeed would be
unreasonable. Yahoo only requires a
On 7/13/23 4:00 AM, Hans-Martin Mosner via mailop wrote:
Has anyone on this list tried forwarding (e.g. for ex-employees) via
attachment?
I have done exactly this on a onesie-twosie / manual basis.
I have .forward files on systems that I administer and can run into
problems when I send an ema
On 7/13/23 10:49 AM, Bill Cole via mailop wrote:
It's not at all logically hard to meet that arbitrary requirement, you
just need a zone cut everywhere you have a MX record. I've run a DNS and
mail hosting environment that way. Zone files are very small and
numerous. *Logistically* changing an
1 - 100 of 327 matches
Mail list logo
