Re: [mailop] Gmail IMAP xyzzy ?
Wow! Now that is bizarre! J. On Mon, 3 Aug 2020, Brandon Long via mailop wrote: > By a complete coincidence, Don Woods worked on Gmail related stuff after we > acquired Postini... but didn't add this code. > > Brandon > > On Sun, Aug 2, 2020 at 3:45 PM John Levine via mailop > wrote: > > > When I connect to Gmail's IMAP server, one of the capbilities it > > advertises is "xyzzy". Anyone know what that is? > > > > I know the etymology (same place as plugh) but what's it supposed to do? > > > > Signed, > > Wondering > > > > ___ > > mailop mailing list > > mailop@mailop.org > > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > > . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks, Network Manager, Information Services Directorate, University Of Strathclyde, Glasgow, UK The University of Strathclyde is a charitable body, registered in Scotland, number SC015263. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] How long to retry?
On Tue, 4 Feb 2020, Paul Smith via mailop wrote: > In my experience, this is very much the case. NDRs are just treated like > spam for many senders, even if they are written in very simple language. Well, they're written in one language (simple or otherwise). Which is a bit of a problem if you don't speak that one. Jethro. . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks, Network Manager, Information Services Directorate, University Of Strathclyde, Glasgow, UK The University of Strathclyde is a charitable body, registered in Scotland, number SC015263. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] News about the travails with my famous Y! trap account
On Tue, 19 Jun 2018, Steve Atkins wrote: > > On Jun 19, 2018, at 8:10 PM, Brandon Long via mailop > > wrote: > > > > They used to use qmail which uses - instead of the more common + for > > multiple addresses, wonder if this is a side effect of the forwarding > > for ymail.com using qmail > > Likely. Though at one point it wasn't unusual to configure the separator > to be - instead of + because of all the web forms that didn't handle > escaping properly and would record "steve+...@blighty.com" as "steve > f...@blighty.com". If they didn't just reject the address as invalid at the start, which was usual. I still have an alias configured (purpose long forgottten), of the form: jrb-bk-plussignsinemailaddressesareperfectlyvalid Jethro. . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks, Network Manager, Information Services Directorate, University Of Strathclyde, Glasgow, UK The University of Strathclyde is a charitable body, registered in Scotland, number SC015263. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] Spam originating from Office 365
On Tue, 6 Feb 2018, Carl Byington wrote: > On Mon, 2018-02-05 at 03:00 +, Shane Clay via mailop wrote: > > For our customers, the bulk majority of spam they actually receive > > (over 90% of whats delivered and more than 40% of whats blocked) now > > days comes from Office 365. Do others see these same trends? > > The percentage is not that high here, but are you using something to > reject mail containing SFV:SPM ? For example, spamassassin: > > header OPOC X-Forefront-Antispam-Report =~ /SFV\:SPM/ > score OPOC 10 I lately asked about this on another mailing list, but didn't get response. Greatful for any views from this community: For some considerable time we've had a rule to increase the score in SpamAssassin based on whether the MS infrastructure it came to us through marked it as spam itself: # protection.outlook.com may determine that an (outbound?) message is spam and adds # to this header. Trust them. # https://technet.microsoft.com/en-gb/library/dn205071(v=exchg.150).aspx header PROTECTIONOUTLOOK_MARKED_SPAM X-Forefront-Antispam-Report =~ /SFV\:SPM/ score PROTECTIONOUTLOOK_MARKED_SPAM 10.0 Now I've seen many cases where this is plainly successful. But I've also had queries for emails from "reputable" sites (including .ac.uk ones) which have also been marked in this, and thus highly scored at our end before delivery. So I'm wondering if something has changed and this isn't so reliable. At the moment, if I get an enquiry, I just make some comment along the lines that MS's infrastructure is closer to the sender, and is in a better position to evaluate whether a message is spam - we simply trust what they say, by virtue of the content in the X-Forefront-Antispam-Report header. Does anyone have any insight into whether this is a reasonable position to maintain now? . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks, Network Manager, Information Services Directorate, University Of Strathclyde, Glasgow, UK The University of Strathclyde is a charitable body, registered in Scotland, number SC015263. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] autoresponders & envelope-from/return-path
On Mon, 5 Jun 2017, Steve Atkins wrote: > > On Jun 5, 2017, at 2:57 PM, Autumn Tyr-Salvia wrote: > > > > Hello, > > > > Any idea what the impact of turning on the return-path for > > autoresponders would be? Colleagues tell me that the hosted mail > > service (Proofpoint) tells their clients not to use a return-path > > address for autoresponders because this is the RFC-correct way to do > > it. We could probably get them to make an exception here, but I'm > > curious if there is any real world impact to that. > > Using a null envelope sender significantly reduces the chance of > auto-responder storms. If they don't have realtime access to their mail > infrastructure to detect and mitigate those (which they don't) anything > they can do to reduce the likelihood of them happening is a good idea. I > think Outlook's OoO has decent-ish behaviour, but OoO vs a VERPing > autoresponder can still ruin your day. If you add the following headers to your message, regardless of the envelope sender, you will also greatly reduce the chances of receiving a reply to your auto-response: Auto-submitted: auto-generated X-Auto-Response-Suppress: OOF Precedence: junk The first from RFC3834 (and that would be the best description of an "RFC-correct way to do it"). The second from Microsoft. The last based on observed behaviour of some systems (I think MS reference it too). Note also that if desgining your own autoreply system, it should make its decisions on whether or not to reply to a given message based on the above criteria; but you would prudently also prime it with a list of sender addresses to which you would not expect to want to send a reply. The most obvious ones would be "donotreply@" or "noreply@", but there are many others. You might consider addresses like "www-data@", "httpd", "bounce@", "root@" too. I've not looked at this area for many years now, but there are also some good tips on this page: https://github.com/jpmckinney/multi_mail/wiki/Detecting-autoresponders Jethro. . . . . . . . . . . . . . . . . . . . . . . . . . Jethro R Binks, Network Manager, Information Services Directorate, University Of Strathclyde, Glasgow, UK The University of Strathclyde is a charitable body, registered in Scotland, number SC015263. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] VERP generating syntactically invalid return-path?
On Mon, 22 Feb 2016, Ian Eiloart wrote:
> > On 16 Feb 2016, at 11:24, Rich Kulawiec wrote:
> >
> > On Wed, Feb 03, 2016 at 10:52:43AM -0800, Brandon Long wrote:
> >> We rolled out a RFC 5321 compliant parser to smtp in Aug/Sept of last year,
> >> to much gnashing of teeth for a small set of users with some crappy
> >> software. We rolled it back for MSA (just silently replace with the
> >> auth-user), because apparently virtually all embedded devices (security
> >> cameras, mostly) send garbage at MAIL FROM.
> >
> > As you know, I'm not a big fan of Gmail, but I fully support your
> > rollout of this and encourage you to enforce it for MSA as well.
>
> I’d love to see that, but it’s so, so hard. Apple can’t get this right,
> for example. Apparently, they can’t spell "undisclosed recipients:;"
> when sending email to groups. They’ve always insisted on saying
> something like this: "undisclosed recipients:<>;", which isn’t valid.
Quite. Here's what my config says now, about my use of Exim's
"header_syntax" verification check:
## header syntax error
## We begrudgingly make some exceptions to this for some common cases:
## + some Microsoft client generates:
## + Apple Mail (2.1084 at least) generates: Undisclosed-recipients: <>;
## We are also very forgiving for some hosts.
##
## Mar2013: very regrettably, I have decided to remove this check. It
## has served us well for many years, but these days the false positives
## are just too much work for me to keep dealing with. It will be
## interesting to see how much spam increases as a result of this; my
## feeling is it will turn out not to be too significant (spammers are
## more wise to the requirement to properly format mail, and less spam
## email now comes from 'spam engines', and more from compromised
## accounts/systems.
## It still feels wrong to be wilfully accepting so-called 'messages'
## that are not formatted according to the standards that define for the
## format of Internet messages, and hence are not, by definition,
## Internet messages, but in this regard most of the end users do not
## agree that this should be the case, so I have now capitualated.
## The tone of this note should be enough to make it clear about my
## unhappiness with this decision, but resources are what they are, and
## I don't have enough of them (or indeed the will) to keep arguing the
## point.
#deny
# !condition = ${if eq{$h_to:}{}}
# !condition = ${if eq{$h_to:}{Undisclosed-recipients: <>;}}
# hosts = !lsearch;HOSTSSYNTAXCHECKEXCEPTIONS
# !verify= header_syntax
# message = Syntax error in the headers of your message.\n\
# $acl_verify_message\n\
# REFUSENOTICE
# log_message = MSGTAG_HEADERSYNTAX: \
# $acl_verify_message
. . . . . . . . . . . . . . . . . . . . . . . . .
Jethro R Binks, Network Manager,
Information Services Directorate, University Of Strathclyde, Glasgow, UK
The University of Strathclyde is a charitable body, registered in
Scotland, number SC015263.___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
