Luis E. Muñoz via mailop wrote:
>
> I did not clarify that this application is actually for a submission server to
> be used by end users with run-of-the-mill MUAs.
The approach we take at Cambridge University (with about 30,000 users) is
to accept and hold messages when a sender is over their ra
John Levine wrote:
>
> Oh, and some MTAs put them in Delivered-To: lines at the top of the
> message, after the Return-Path:.
Or Envelope-To:
http://www.exim.org/exim-html-current/doc/html/spec_html/ch-message_processing.html#SECID225
Tony.
--
f.anthony.n.finchhttp://dotat.at/ - I xn--zr
Marc Perkel wrote:
>
> Rather that just scan for regex strings it's useful to have a way to tell what
> things the message is talking about and reduce those to a single token that
> represents a concept. Then the concepts can be combined to produce rules or
> fed into Bayes for automatic scoring.
Dave Warren wrote:
>
> They're broken by design and not fit for purpose. Among their many flaws, they
> don't even make it to RFC821 3.1, the MAIL command, which is described as the
> following:
>
> MAIL FROM:
>
> Instead, when they receive a "M" in a packet alone, they interpret it as an
> inva
Franck Martin via mailop wrote:
> This page, provides a way to test EDNS:
> https://www.dns-oarc.net/oarc/services/replysizetest
That's testing the EDNS large packet feature. A DNS server can support
EDNS without supporting large packets.
Tony.
--
f.anthony.n.finchhttp://dotat.at/ - I xn
Michael Wise wrote:
>
> So is the FORMERR ... just the resolver noting that EDNS is not supported?
>
> If so, I'm uncertain of the issue.
There has been some discussion of this problem on the bind-users list, see
https://lists.isc.org/pipermail/bind-users/2016-May/thread.html
The problems seem t
Renaud Allard via mailop wrote:
> On 04/19/2016 09:15 AM, Michelle Sullivan wrote:
> >
> > As well... ;-) (and for those that don't get it... the host issued 'HELO
> > [65.55.234.213]' or 'EHLO [65.55.234.213]' .. perfectly legal but
> > something malware and bots do as well..
>
> While HELOing li
Thomas Wilhelm wrote:
>
> Does anybody have a hint for us, how to fix this problem?
To send mail to Google over v6 you have to have SPF, DKIM, reverse DNS,
everything set up to the best anti-spam standards.
Tony.
--
f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode
Southeast Iceland
Franck Martin via mailop wrote:
>
> This could be true but then RFC7505 is recent, so I'm not sure that proper
> MTAs are yet properly behaving. I wonder what sendmail, postfix, exim
> really do?
Exim has treated null MXs as invalid since 2004.
https://www.ietf.org/mail-archive/web/apps-discuss/c
Suresh Ramasubramanian wrote:
> A domain with a null mx may well originate email
If they try to do that they will be sad.
A lot of MTAs will reject email with a MAIL FROM using a domain that is
invalid according to the DNS, and a null MX counts as invalid for this
purpose.
Tony.
--
f.anthony.
David Hofstee wrote:
> If he knows that no forwarded mail should be sent via his mailserver,
> spf should be fine, right?
No, a sender with an SPF -all record needs to be certain that none of
their users ever send mail to an address which forwards elsewhere. Of
course it's unreasonable to expect
David Hofstee wrote:
> Ian Eiloart wrote:
> >
> > ... I prefer to call that a rejection rather than a bounce. ...
>
> https://xkcd.com/927/
This isn't competing standards, this is a fundamental feature of one
standard. Ian is prefering to use exactly the same terminology as
RFC 5321 section 6.2:
Brandon Long wrote:
>
> I won't claim our failure mode here is correct for all cases, but the flip
> side is, this is what you get with dnssec by design.
By design the DNS distinguishes between nonexistent (i.e. NXDOMAIN or
NODATA) and failure (SERVFAIL). If there is a security error DNSSEC gives
Franck Martin wrote:
> It depends if it is at connection time, or after the RFC5321.MailFrom where
> the SPF can be evaluated. If there is no valid rDNS and no SPF, rejecting
> after SPF evaluation may not be a bad solution,
If there is a DNSSEC failure you can't tell whether or not there is any
Franck Martin wrote:
> http://dnsviz.net/d/5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.7.2.0.0.1.0.0.0.0.0.1.5.0.4.2.ip6.arpa/dnssec/
Gmail should treat that as a temporary error not a permanent one.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Biscay: Southwesterly 5 or 6 in northwest, otherwise, nor
SM wrote:
> At 13:22 16-10-2015, Luke M wrote:
> >
> > I was wondering if anyone would share their thoughts on RFC 1123 section
> > 5.2.2. It states:
> >
> > The domain names that a Sender-SMTP sends in MAIL and RCPT
> > commands MUST have been "canonicalized," i.e., they must be
> > fully-qualif
Gil Bahat wrote:
> additionally, if all providers were to respect the
> non-standard-but-should-be x-auto-response-suppress , it would do well to
> stop this from hitting prudent transactional senders.
They ought to implement RFC 3834.
> funny thing is, this is a microsoft-specific (well, outlo
17 matches
Mail list logo
