On Fri, May 17, 2024, Cyril - ImprovMX via mailop wrote:
> So, I wonder, is there another RFC that specifies a bigger line length,
No.
> or are the RFC here just for decoration?
"We don't care. We don't have to. We are the phone company".
Of course you could argue to "be nice and accept
On Thu, Mar 14, 2024, Marco Moock via mailop wrote:
> Am 14.03.2024 schrieb Julian Bradfield via mailop :
> > On 2024-03-14, Marco Moock via mailop wrote:
> > > sendmail tried to deliver it 20 times during the night - this
> > > morning I deleted the mail from mqueue.
> That is the default in
On Wed, Mar 13, 2024, Harald Hannelius via mailop wrote:
> Are there SMTP-"clients" that actually are able to back down from STARTTLS
> and continue unencrypted?
Very unlikely. If the TLS handshake fails, a server usually drops
the session because it is in an unknown state.
What several clients
On Tue, Feb 27, 2024, Matt Palmer via mailop wrote:
> > 550-5.7.26 DKIM = did not pass 550-5.7.26 SPF [nagler.me] with ip:
> Any chance of a transient/intermittent DNS failure on nagler.me? On
That should not result in a permanent (550) error but
just cause a temporary (4xy) error.
--
On Sat, Jan 13, 2024, Sebastian Nielsen via mailop wrote:
> Why is it a problem? The server ignores commands that it don't have
> capability for anyways.
Says who?
555 MAIL FROM/RCPT TO parameters not recognized or not implemented
--
Please don't Cc: me, use only the list for replies,
On Mon, Jan 01, 2024, John Covici via mailop wrote:
> I use sendmail 8.17.1.9 under gentoo -- any patch for that one to fix this?
Upgrade to 8.18.0.2,:
https://ftp.sendmail.org/snapshots/sendmail.8.18.0.2.tar.gz
https://ftp.sendmail.org/snapshots/sendmail.8.18.0.2.tar.gz.sig
On Tue, Dec 19, 2023, Slavko via mailop wrote:
> Please, understand i properly, that it is no vulnerabiliy in SMTP itself,
> but in (some) implementations/servers only?
The RFC is very precise about line endings and "end of message".
Some (legacy) MTAs try to be "nice" and accept other line
On Mon, Dec 18, 2023, Paul Smith* via mailop wrote:
> DKIM (and SPF) aren't anti-spam measures, and have never been promoted as
> such. They're anti-forgery measures.
I know that -- which is why I don't use either (besides other reasons,
e.g., breaking existing mail mechanisms).
> spammers can
On Mon, Dec 18, 2023, Gellner, Oliver via mailop wrote:
> On 17.12.2023 at 21:48 Michael Peddemors via mailop wrote:
> > A bit off topic, but it is always amazing.. rejecting based on no DKIM?
> > It's like most new requirements, ever notice that the spammers are
> > implementing these
On Sat, Dec 16, 2023, Thomas Walter via mailop wrote:
> I still think Microsoft should not complain about NDRs, especially if the
> original was from them.
That's probably just the normal case of filtering mail when it is
coming in, but not when it is going out (that's what those companies
do,
On Sat, Dec 16, 2023, Thomas Walter via mailop wrote:
> 2. Our server bounces with 550 5.1.1 User doesn't exist.
Does your server generate a DSN?
If the "User doesn't exist" then it seems you should be able to
determine that fact when RCPT is given -- or is this just a bogus
reply?
--
Please
On Fri, Oct 27, 2023, Marco M. via mailop wrote:
> Am 27.10.2023 um 15:19:33 Uhr schrieb Cyril - ImprovMX via mailop:
> > For instance, if my server has a PTR with mail1.example.com, and I
> > connect by saying "HELO send.example.com". If the receiving server
> > loads all the IPs for
On Mon, Sep 11, 2023, Camille - Clean Mailbox via mailop wrote:
> 2023-09-11T22:47:26.496119+02:00 mx1 postfix/smtpd[850937]: warning: TLS
> library problem: error:0AC1:SSL routines::no shared
> cipher:../ssl/statem/statem_srvr.c:2220:
Did you change the default TLS settings (of postfix),
On Wed, Aug 30, 2023, Dan Mahoney (Gushi) via mailop wrote:
> I've also discovered (over on comp.mail.sendmail) that SpamHaus's
> recommended, documented use of the enhdnsbl feature DOES NOT WORK, which I
You should have read the fine (sendmail) documentation instead:
FEATURE(`enhdnsbl',
On Wed, Aug 23, 2023, Dan Mahoney (Gushi) via mailop wrote:
> It looks like the version of enhdnsbl.m4 simply checks for *any* return code
Have you checked the fine documentation?
cf/README:
enhdnsblEnhanced version of dnsbl (see above). Further arguments
(up to 5) can
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
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
On Tue, Jul 11, 2023, Grant Taylor via mailop wrote:
> I have seen a-record fallback work, as in legitimate email flow, for others
> within the last two years.
> I have not been able to get it to work in my testing.
Maybe you can explain how you tested it and which software (MTA?)
was used?
--
On Tue, Jul 11, 2023, 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
Maybe you should have looked for "MX" instead of "fall"?
... If
no MX records are
On Tue, Jul 11, 2023, Grant Taylor via mailop wrote:
> I think that A-record fallback is dependent on the sending MTA.
And which MTA are those which do not implement the RFCs properly?
"We are ..., we don't care about standards"
> Though if memory serves that's because my MTA of choice balks at
On Sun, Jun 25, 2023, Carsten Schiefner via mailop wrote:
> The question, however, is: will it ble..., erm, can one do without
> greylisting?
It would mean more spam is coming through - so for my case greylisting
is not useless -- which was the unsubstantiated claim to which I
replied.
--
On 6/23/2023 9:13 PM, Al Iverson via mailop wrote:
> What if we just got to the heart of the matter and admitted that
> greylisting is useless 2023?
It isn't.
(it works fairly well for the way I'm using it...)
--
Please don't Cc: me, use only the list for replies, even if the
mailing list
On Mon, Apr 03, 2023, Jay Hennigan via mailop wrote:
> Final-Recipient: rfc822; ab...@asalesforce.com
Does that mean ab...@salesforce.com is redirected to
ab...@asalesforce.com ?
--
Please don't Cc: me, use only the list for replies.
___
mailop
On Tue, Feb 28, 2023, Andrew C Aitchison via mailop wrote:
> Is there an SMTP equivalent of the HTTP 30x status codes ?
Maybe this: RFC 5321:
551 User not local; please try (See Section 3.4)
--
Please don't Cc: me, use only the list for replies.
On Sun, Dec 25, 2022, Peter Nicolai Mathias Hansteen via mailop wrote:
> but since they have no valid MX record
What's wrong with the MX records?
dig antispamcloud.com. mx
antispamcloud.com. 600 IN MX 10 filter10.antispamcloud.com.
antispamcloud.com. 600 IN MX
On Sun, Nov 27, 2022, Hans-Martin Mosner via mailop wrote:
> > IMHO it would be nice if those (misleading) "tags" could be removed
> > before replying,
sorry if I wasn't clear: I meant removed by the person who is
replying, not by some software.
> Of course he could have removed that
> tag by
Hmm, so something "tagged" the previous mail as
[Marketing Email]
Subject: Re: [mailop] [Marketing Email] t-online.de
Seems to be really bogus to me
IMHO it would be nice if those (misleading) "tags" could be removed
before replying, similar to "[External]", "[Probably Spam]", etc,
esp. if
On Nov 21, 2022, at 18:29, John Levine via mailop wrote:
> I understand why that's the conventional wisdom, but I also don't
> understand why, if all the resources are on the same LAN as the name
> servers, the conventional wisdom would apply.
This doesn't apply to postfix.org -- the mailing
On Thu, Oct 27, 2022, Otto J. Makela via mailop wrote:
> Unfortunately sendmail doesn't seem to have anything to do this on
> a permanent basis (ref: Claus AÃmann on comp.mail.sendmail), I'd be
> fine with IPv4 outgoing IPv4/IPv6 incoming.
A patch has been posted to comp.mail.sendmail,
but
On Sat, Oct 29, 2022, Benny Pedersen via mailop wrote:
> https://multirbl.valli.org/fcrdns-test/2a01%3A111%3Af400%3A7d00%3A%3A33.html
> such clients will not deliver email here, as the t-online.de dont accept
It seems those were supposed to be servers. Do you have
any evidence that they were
On Thu, Oct 27, 2022, Peter Beckman via mailop wrote:
> Deferred: 451 4.7.500 Server busy. Please try again later from
> [2a01:111:e400:7e0d::51]. (AS750)
Doesn't the MTA (which one do you use?) also try IPv4
or were there no A records at all?
Do you still have the results for the
"What's the problem you are trying to solve?"
Almost no MTA cares about the certificate content unless explicitly
configured to do so. Some check the names (CertSubject or AltNames),
and some are "misconfigured" to require a cert signed by some
specific CAs.
Testing with just one or two other
My system is getting spammed by outbound.protection.outlook.com
mail=
rcpt=, stat=550
rcpt=, stat=550
and this happens again and again.
(note: it happened before with other MAIL addresses)
It their MTA broken -- ignoring 550 for RCPT?
Or is the sender submitting the mail again and again?
the
On Sat, Sep 03, 2022, Carl Byington via mailop wrote:
> A former client was trying to setup Fedora 36 sendmail with dane
> validation. F36 comes with sendmail 8.17.1 which is supposed to support
> dane, but they get verify=fail talking to my mail servers. So I googled
If would have been nice if
How did you notice that "something is now broken"?
"works for me" - I just tried it with an MTA that supports DANE:
server=172.102.240.42,
starttls=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, verify=DANE_SEC,
cert_subject=/CN=mail3.five-ten-sg.com,
cert_issuer=/C=US/O=Let's+20Encrypt/CN=R3,
> _25._tcp.mail3.five-ten-sg.com. IN TLSA 3 0 1 (
> 834d710b2feb790cc9b2c6d251c65b1fedc24c51a4149bdfeae4d40e0be11892
Are you sure you want 3 0 1 and not 3 1 1?
Isn't the second number the selector:
0 -- Full certificate: the Certificate binary structure as defined in [RFC5280]
1 --
On Fri, Aug 19, 2022, Michael Peddemors via mailop wrote:
> Sorry, thought it was clear, they are using bare line feeds on their
> injected headers..
Hmm, I've seen that bug before in some software at $WORK :-(
They didn't even notice it until some DKIM verifier finally failed
due to that bug.
On Fri, Aug 19, 2022, Michael Peddemors via mailop wrote:
> The reason we are seeing this behavior for 2 antivirus: Both AVG and
Can you share which "bad modifications" are made?
--
Address is valid for this mailing list only, please do not reply
to it directly, but to the list.
My system is getting spammed by outbound.protection.outlook.com
First they are sending every 10 minutes to the same two unknown
addresses until I blocked the sender (@emss.gov.eg) then it stopped.
Now they are sending to the same addresses using
lr...@incm.gov.uk
as sender -- AFAICT the domain
Can you give an example which shows this behaviour?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
On Fri, Jul 15, 2022, Michael Ellis via mailop wrote:
> C:\Users\philipt>nslookup -q=mx csc-emarketing.trimaxdirect.com
The MX record has nothing to do with this simple check.
> 7/13/2022 11:12:35 AM Mail server: 550-5.7.25 [173.160.100.85] The IP
> address sending this message does not have a
On Fri, Jul 15, 2022, Michael Ellis via mailop wrote:
> Am I missing something as well? Google just rejected a client due to
> PTR on mailop-boun...@mailop.org but it seems fine to me
What is "PTR on mailop-boun...@mailop.org"?
Can you post the rejection and the relevant logs?
On Wed, Jul 13, 2022, Philip Paeps via mailop wrote:
> As far as I can tell, the message is compliant. It doesn't have any of the
Can you post it so others can check?
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
On Mon, Jun 20, 2022, Grant Taylor via mailop wrote:
> When was the last time that anyone has seen the fall back to A record work?
Which broken software has this bug? (an obvious RFC violation --
an "MTA" of one of those companies who don't care about RFCs anyway?)
It works fine in the MTAs
On Thu, Jun 09, 2022, Johann Klasek via mailop wrote:
> The whole line may look like this:
> sendmail[12403]: 259I6JFw012399: to=, delay=00:00:01,
> xdelay=00:00:01, mailer=esmtp, pri=139340, relay=gmail-smtp-in.l.google.com.
> [IPv6:2a00:1450:400c:c00::1b], dsn=5.0.0, stat=Service unavailable
On Tue, Apr 05, 2022, Paul Vixie via mailop wrote:
> google e-mail addresses were signing up en masse for mailman lists here, and
> the resulting confirmation e-mail from mailman was seen by google as spam.
> i've since turned off confirmation e-mail, and i've added SPF checking to
"confirmation
On Thu, Mar 03, 2022, Bill Cole via mailop wrote:
> Did I miss something?
Maybe... I provided examples before.
> I have no idea what GMail is rejecting in SMTP
See Message-ID: <20220302163128.ga95...@veps.esmtp.org>
I have no idea why GMail rejected those mails at the final dot.
> and no one
On Thu, Mar 03, 2022, Bill Cole via mailop wrote:
> Interestingly, none of my GMail accounts has ever had ham misclassified as
> spam.
Again: how do you know whether you didn't even receive a "ham"
e-mail because it was "misclassified as spam" and rejected during
the SMTP dialogue? Do you get a
On Wed, Mar 02, 2022, Graeme Fowler via mailop wrote:
> Whilst I may occasionally - like 5 or 6 times a year - have something that
> lands in the Junk folder, I almost _never_ receive âobviousâ spam in the
> Inbox, and neither do they.
How do you know you are not missing (important) mail?
On Thu, Feb 10, 2022, Bill Cole via mailop wrote:
> Yes, Microsoft has a chronic endemic problem of broken reverse DNS,
> in both IPv4 and IPv6. It cannot be relied upon.
So does Google reject mail from those misconfigured Microsoft systems?
--
Please don't Cc: me, use only the list for
On Sun, Dec 05, 2021, Slavko via mailop wrote:
> I think a little about it, but i cannot find other way than do not use
> To: header at all, which will be penalized in my anti-spam SW latter.
"What's the problem you are trying to solve?"
Is this about the differences between envelope and
On Sun, Dec 05, 2021, Slavko via mailop wrote:
> But, please, what about header:
> To: postmaster
> ... rejected after DATA: header syntax: unqualified address not
> permitted: failing address in "To:" header is: postmaster
The syntax for envelope addresses and header addresses is
On Sun, Dec 05, 2021, Alessandro Vesely via mailop wrote:
> 220 resimta-h1p-037571.sys.comcast.net resimta-h1p-037571.sys.comcast.net
> ESMTP server ready
> rcpt to:
> 550 5.1.1 Not our customer
RFC 5321 SMTP October 2008
o The reserved
I am not criticizing qmail for this behaviour. If you need another
example:
The Postfix smtp(8) client normally does not wait for the server's
reply to the QUIT command, and it never waits for the TCP final
handshake to complete.
So now you have two people, who know that they are doing, having
On Wed, Nov 24, 2021, Michael Peddemors via mailop wrote:
> And then it terminates the connection, SSL collapses, without waiting for
> the remote mail server to acknowledge the QUIT.
Just like qmail?
Maybe it's time to change the RFC?
___
mailop
On Sat, Jul 03, 2021, John Levine via mailop wrote:
> >Mail from this host was rejected by a strict check:
> >citaprevia.maspalomas.com. 300 IN MX 10 82.98.157.67.
> To ask a fairly obvious question, since they clearly don't care whether they
> ever get
> any mail, why would
Mail from this host was rejected by a strict check:
citaprevia.maspalomas.com. 300 IN MX 10 82.98.157.67.
I sent mail to
postmas...@citaprevia.maspalomas.com
postmas...@maspalomas.com
dnsad...@tsai.es
the latter due to:
maspalomas.com. 300 IN SOA
On Tue, Apr 06, 2021, Michael Grimm via mailop wrote:
> Will you at t-online.de accept DANE/TSLA as an alternative?
How does DANE/TLSA help the recipient (server) to "verify" the
sending host?
> Or do I need to add DKIM signing in addition?
coming next:
"you must include a copy of your
On Fri, Jan 22, 2021, Patrick Ben Koetter via mailop wrote:
> The only reference to PRDR I could find, is an expired RFC draft. Is that what
> you are referring to?
Yes. Something like this:
Eric A. Hall. Smtp service extension for per-recipient data responses
(prdr). Draft, Internet
On Fri, Jan 22, 2021, Benot Panizzon via mailop wrote:
> Now Assume two recipients with different Anti-Spam Settings:
...
That's what PRDR is for, but it isn't supported by many MTAs
or setups :-(
___
mailop mailing list
mailop@mailop.org
On 17.12.20 23:07, Mark Fletcher via mailop wrote:
> If this is really an issue, why don't we have backup A records as well?
> My website is just as important as my MXes, yet I do just fine without A
> record priorities...
This is somewhat off-topic here, but I guess you would use multiple
A
On Wed, Sep 30, 2020, Tim Bray via mailop wrote:
> Should it be using TLS for outbound connections??? I'm not seeing that?
Received: from mx.mailop.org (mx.mailop.org. [91.132.147.157])
by ... with ESMTPS
(TLS=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384, bits=256, verify=OK)
>
On Mon, Aug 31, 2020, Mark E. Jeftovic via mailop wrote:
> So the list archives are still down then?
I tried to contact owner- about it but got a bounce,
while request- was at least delivered.
> I was hoping to link to a thread.
I was looking for that too and found
https://www.mail-archive.com/
On Wed, Aug 26, 2020, Michael Peddemors via mailop wrote:
> There SHOULD be a URL associated with the domain ('mydomain.com') in the PTR..
Ah, the stuff you suggested on ietf-smtp and which got "rejected" by
pretty one every one who replied?
___
> But it was enough to have the imprint visible for them just for the
Sorry for a stupid question: What is "the imprint"?
Does that mean you have to operate a web server with an "Impressum"
(I guess that's the German word?) if you want to send mail?
On Sun, May 17, 2020, Alessio Cecchi via mailop wrote:
> the domain name is stefanoboschi.it and after the transfer from one
dig stefanoboschi.it. mx
stefanoboschi.it. 3500IN MX 10 mx01.cbsolt.net.
stefanoboschi.it. 3500IN MX 20 mx02.cbsolt.net.
Talking about RDNS issues:
Since Saturday bankofamerica.com seems to have a problem with their
DNS too -- I tried to contact them directly but (so far) nothing
happened.
Their "alerts" are sent by hosts with IPs like
68.232.194.1 - 68.232.194.14 (exacttarget?)
which map to
On Mon, Feb 17, 2020, ngel via mailop wrote:
> I contacted them in order to warn them about the issue. They are not
> aware of any email issue and asked for the destination mailbox that had
> problems.
I was given the e-mail address
correosduap...@correos.es
from a local post office and it
I hope this is the right place to ask questions like this. I've
been in contact with correos.es for a while about a problem with a
package the is on the way to me.
But for about two weeks now their mailserver is no longer reachable
from my hosts (I tried 3 different hosts in 3 different
Usually I don't reply to top-posted mails...
1. Try with
openssl s_client -connect other.host:25 -state -debug -crlf -starttls smtp ...
and add parameters to match your sendmail setup.
2. See cf/README how to set the option in your mc file:
confCIPHER_LIST CipherList [undefined]
On Thu, Jan 23, 2020, John Covici via mailop wrote:
> Jan 23 17:51:33 debian-2 sm-mta[7625]: STARTTLS=client, error: connect
> failed=-1, reason=dh key too small, SSL_error=1, errno=0, retry=-1
AFAICT it's the key from "the other side" that openssl is complaining
about -- did you recently
I don't read HTML mail unless absolutely necessary (i.e., I "need"
the information that the mail contains); I don't want to trigger
all the tracking stuff in the HTML part.
___
mailop mailing list
mailop@mailop.org
> MAIL FROM: @marketplace.amazon.in
A strict syntax check would reject this
:-)
(e.g., no space after : allowed)
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
On Sun, Nov 24, 2019, Michael Orlitzky via mailop wrote:
> For the same reason, I would recommend verifying the addresses against a
> simple regular expression to catch typos, rather than against the full
> rfc5322 grammar which allows basically anything.
Hopefully not the one which is used on
On Sat, Nov 23, 2019, Tom Ivar Helbekkmo via mailop wrote:
> In the olden days, one would simply write a script, using expect(1) or
> similar, to go through the addresses, connect to the target MTAs, and do
> an SMTP VRFY on the recipient address. Today, I suspect that most MTAs
Some MTAs have
On Thu, Nov 21, 2019, Carl Byington via mailop wrote:
> My servers have Let's Encrypt certs for sendmail, and receive a fair bit
> of mail from mimecast.
Just to clarify: If I understand it correctly, there are configuration
options how to handle STARTTLS which mimecast customers can modify,
On Wed, Sep 18, 2019, Michael Rathbun via mailop wrote:
> opened or clicked within the past four months, and says, essentially, "If you
> want to continue to receive email from us, click here. Otherwise, you won't
I hate that stuff... beside the annoyance of requiring web stuff
to receive info
77 matches
Mail list logo
