gmane.mail.fetchmail.user

Re: Unknown recipient ends up being 2 messages for Postmaster

Matthias Andree — 2013-06-14T17:44:06

Am 14.06.2013 17:13, schrieb Stephan Pieri:

Good afternoon Stephan,

It is.


Update unless you are positively certain your packager has backported
all security fixes.


Check the manual for bouncemail to see what it does, and then flip the
switch.

HTH
Matthias

Unknown recipient ends up being 2 messages forPostmaster

Stephan Pieri — 2013-06-14T15:13:14

Good afternoon.

Firstly, apologies if this is not the correct list to request help from.

If it is the correct list, great.

I have Fetchmail 6.3.8 installed and the configuration is

***
set syslog
set postmaster "undeliverables< at >domain1.com"
set nobouncemail
set no spambounce
set properties ""
set daemon 900
set invisible

poll www.domain1.com with proto POP3 no dns
localdomains domain1.com, domain2.com, domain3.com
user 'USER' there with password 'PASSWORD' is * here options
smtphost xxx.xxx.xxx.xxx

***

The issue we are getting is that when an external email is received with an unknown user, the message along with an NDR goes into the undeliverables mailbox. On further testing using my gmail account and sending to an unknown user, the sender does not get the NDR.

I think this was setup to prevent spam being sent, but maybe it was setup a bit too tough (before my time by a genius by the looks of it)

Any help would be greatly appreciated and, once again, sorry if this is the wrong list.

Thank you,
Step

AOL authorization error (not a problem)

Johann 'Myrkraverk' Oskarsson — 2013-06-01T22:03:57

Hi all,

For the record, I just got this error in my log today:

fetchmail: Authorization failure on myrkraverk< at >nginx.mx.aol.com.aol.akadns.net
fetchmail: For help, see http://www.fetchmail.info/fetchmail-FAQ.html#R15
fetchmail: Query status=3 (AUTHFAIL)

The reason is that I didn't use the account for several months and AOL
had closed the mail.

After logging in on the website, and I had an empty mailbox with the usual
greeting, fetchmail worked again.  Still with the same password in my
.netrc.

I don't know if this merits a mention in the FAQ, but maybe someone else
will run into this message when searching the web.


Johann

Re: Accept emails with malformed sender address / domain name with exim 4 on Debian 7.0

Matthias Andree — 2013-05-21T05:34:11

Am 20.05.2013 23:15, schrieb Xianwen Chen:

Xianwen,

Note that there isn't much you can configure in fetchmail in this respect.

Please provide information as per

<http://www.fetchmail.info/fetchmail-FAQ.html#G3>
(be sure to remove passwords including base64 transcripts from logs and
configuration!)

Chances are that part of the problem is with Exim's configuration; it
would likely also reject broken headers, but this list isn't about Exim
support.

The fetchmail verbose logging will help us identify which part of your
setup refuses the mail.

Best regards,
Matthias Andree

Accept emails with malformed sender address / domain name with exim 4 on Debian 7.0

Xianwen Chen — 2013-05-20T21:15:10

Hi,

I installed exim4-daemon-heavy on a Debian 7.0 machine. I use fetchmail 
to retrieve emails. Some emails have malformed sender addresses, like 
'miss zhang< at >gmail.com'. Some emails have malformed domain names, like 
'foo< at >.com'. Most of these emails are spams. Only few may be sent from a 
badly configured server.

I would like to receive all emails, including those that have bad 
sender-addresses and wrong domain-names. Can you help me with this? 
Thank you in advance!

Kind regards,

Xianwen

Re: Changing the logging style of fetchmail

Matthias Andree — 2013-05-17T16:56:17

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 17.05.2013 14:39, schrieb Jerry:

Jerry,

Next time, please use "example.org", "example.com", or ".invalid" or
".example" TLDs for that so you don't have spammers harrass the innocent.

[...log snipped...]


Yes, that's a sensible suggestion, will put it on my TODO list. It will
probably also be useful to include the "250 Ok" line from the SMTP/LMTP
listener because that can contain the queue ID of the next stage.
Postfix would for instance show "250 2.0.0 Ok: queued as 8770723D2B1".

Thank you for taking the time to write this up.

Best regards
Matthias

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlGWYSwACgkQvmGDOQUufZVIoACginZvfVrKeN47TiwIc7YMjXoR
WtUAoJa3PU+/RDzgwPuZz9RKibUKFQQq
=oKje
-----END PGP SIGNATURE-----

Changing the logging style of fetchmail

Jerry — 2013-05-17T12:39:13

When using logging with fetchmail, this is the normal output.
Obviously, I have altered the actual names to protect the innocent.

fetchmail: 1 message for user< at >domain.net at imap.gmail.com.
fetchmail: reading message user< at >domain.net< at >gmail-imap.l.google.com:1 of 1 (4365 header octets) (1114 body octets) flushed

That same message when handed over to Postfix produces this logging:

May 17 08:20:32 mypc postfix/smtpd[53591]: connect from localhost[127.0.0.1]
May 17 08:20:32 mypc postfix/smtpd[53591]: 3bBpVm4c5Bz2CG5q: client=localhost[127.0.0.1], sasl_method=CRAM-MD5, sasl_username=secret< at >domain.net
May 17 08:20:32 mypc postfix/cleanup[53597]: 3bBpVm4c5Bz2CG5q: message-id=<20130517131932.03450167< at >sender.domain.com>
May 17 08:20:32 mypc postfix/qmgr[5884]: 3bBpVm4c5Bz2CG5q: from=<mailing_list< at >domain.org>, size=5631, nrcpt=1 (queue active)
May 17 08:20:32 mypc postfix/pipe[53598]: 3bBpVm4c5Bz2CG5q: to=<user< at >domain.net>, relay=dovecot, delay=0.17, delays=0.15/0/0/0.01, dsn=2.0.0, status=sent (delivered via doveco

Re: Getting a certificate's fingerprint

Volker Kuhlmann — 2013-05-05T21:05:06


The easiest way to obtain *a* fingerprint is 

  fetchmail -d0 -c -v gmail.com

from the command line.
Note that this gives you no way of verifying that this fingerprint
displayed by fetchmail actually belongs to gmail.com, so use at your own
risk.

Volker

Re: Getting a certificate's fingerprint

Matthias Andree — 2013-05-04T10:20:44

Am 02.05.2013 23:04, schrieb Jerry:


The FreeBSD .crt file installed by
http://www.freshports.org/security/ca_root_nss/ is a certificate bundle
containing currently 158 certificates in PEM format and is suitable for
fetchmail use, and installs into the default location.

And quite intentionally, the FreeBSD mail/fetchmail port and package
require the former to run (so it will be installed).

Re: Getting a certificate's fingerprint

James Cloos — 2013-05-04T09:39:13

J> I am on FreeBSD. The distro certs file is "ca-root-nss.crt" and
J> fetchmail needs the certificates in PEM format,

A number of distributions use Debian's package.  Try:

git://git.debian.org/git/collab-maint/ca-certificates.git

That includes all of the certs published by mozilla (which matches the
crt file freebsd provides), debian, spi-inc.org and cacert.org.

-JimC

Re: Getting a certificate's fingerprint

Jerry — 2013-05-02T21:12:25

On Thu, 02 May 2013 22:14:48 +0200
Matthias Andree articulated:


I just discovered that this works fine:

fetchmail -d0 -vk imap.gmail.com

Re: Getting a certificate's fingerprint

Jerry — 2013-05-02T21:04:17

On Thu, 02 May 2013 22:14:48 +0200
Matthias Andree articulated:


I am on FreeBSD. The distro certs file is "ca-root-nss.crt" and
fetchmail needs the certificates in PEM format, unless I am mistaken. I
don't know of a way to remove all of the "PEM" certificates in the
"crt" file other than doing each one manually.

Re: Getting a certificate's fingerprint

Matthias Andree — 2013-05-02T20:14:48

Am 02.05.2013 11:37, schrieb Jerry:

Unless you have a reliable way to get them (by fax, from a https website
that uses different certificates that you trust, from a GnuPG-signed
mail with a signature that you trust), it's pointless.

So either ask Google to publish the fingerprints of their server keys or
just go with the distro's certificates.

Re: Getting a certificate's fingerprint

Rob MacGregor — 2013-05-02T18:37:41


It might be easier for you to install your distribution's CA certificate
package so that verification can take place that way (just like it does in
your web browser).

Re: Getting a certificate's fingerprint

grarpamp — 2013-05-02T17:36:53

openssl s_client -connect pop.gmail.com:pop3s </dev/null 2>/dev/null |
openssl x509 -noout -fingerprint

If your point is to avoid being mitm'd, you should use some
other location/means to obtain/verify this data.

Getting a certificate's fingerprint

Jerry — 2013-05-02T09:37:08

I use the option "sslfingerprint" in my config file. Every time GMail
changes its certificate, I have to get a new fingerprint or else
fetchmail refuses to fetch the mail. That is fine. My problem is, how
to get the fingerprint. I have not found an easy method of doing it.
Since I am not an expert with SSL, that is understandable I suppose.

I ws hoping that someone could give me an example of an easy method to
optain the new fingerprint of a GMail certificate that I could use
every time they change theirs.

Thanks!

Fwd: Re: fetchmail doesn't want to connect to my mysql database

Clement BRIZARD — 2013-04-26T18:16:54

Le 23/04/2013 21:52, Robert Dahlem a écrit :

That's it, I changed the fetchmail.pl from

our $db_type = 'Pg';#
my $db_type = 'mysql';

# host name
our $db_host="127.0.0.1";
# database name
our $db_name="postfix";
# database username
our $db_username="postfix";
# database password
our $db_password="my password";


to

#our $db_type = 'Pg';
my $db_type = 'mysql';

# host name
my $db_host="127.0.0.1";
# database name
my $db_name="postfix";
# database username
my $db_username="postfix";
# database password
my $db_password="my password";

I didn't saw that the first time


Thank you very much both of you



_______________________________________________
fetchmail-users mailing list
fetchmail-users< at >lists.berlios.de
https://lists.berlios.de/mailman/listinfo/fetchmail-users

Re: fetchmail doesn't want to connect to my mysql database

Matthias Andree — 2013-04-26T18:01:57

Clement,

you are not having fetchmail troubles, but instead your postfixadmin rig
is incapable of producing its configuration or whatever it is that it is
trying to pull from your SQL server.  It would not seem that your setup
has even tried to start your (outdated) fetchmail version.

This is neither a Postfix nor a Fetchmail problem, but one with
Postfixadmin, or the fetchmail addition for Postfixadmin, which is not
part of fetchmail.

Please try the Postfixadmin support channels, you will morely likely
find people there who can really help.

Once you have reached the point where you can show us the fetchmail
command line and logs, we will probably be able to help from there, but
you are not yet at that point.

Sorry we can't help you now.

Best regards
Matthias

Re: master: TODO.txt

Matthias Andree — 2013-04-25T07:16:09

Am 24.04.2013 10:37, schrieb grarpamp:

Up front, thanks a bunch for the feedback.  We should move to
fetchmail-devel though...

I am wondering - especially about switching SSL library, too, because
OpenSSL requires you to jump quite through a few hoops for even standard
stuff, like CRLs and OCSP.



<http://svnweb.freebsd.org/ports/head/security/ca_root_nss/files/MAca-bundle.pl.in?revision=312617&view=markup>


This line is to be dropped from TODO.txt -- I've seen too many
certification "authorities" that did not deserve this name, and I seem
to have someone willing to tell users in the fetchmail lobby how to make
_good_ use of this feature.

The missing link is that you hardly ever get the certificate
fingerprints on the "how to configure Outlook, blahmail, whatever for
fetching mail from us" on the ISP help pages, or even better, by snail
mail when they send you account data.


Basically we're already quite close, we'd only have to make sure that
adding a poll argument on the command line permits specifyi

Re: master: TODO.txt

grarpamp — 2013-04-24T20:07:13

typo: host BAR1 password is an account option, not a host one.

master: TODO.txt

grarpamp — 2013-04-24T08:37:16

Noted some things

- blacklist DigiNotar/Comodo/T<C3><BC>rktrust hacks/certs, possibly
with Chrome's serial# list?

I would not hardcode this but instead place fingerprints in multiple
global/per_host 'fpdeny' config options. In part because testing
infrastructure with these certs is valuable. And at least that way,
even if they're lazy and only use sslcertck, if some emergency
arises they can add a negative print there affecting global/per_host.
Additionally, point the user to where they can find and then build
their own updated cert store free from all such junk. As well as
point them to some doc about the importance of fingerprint checking.

https://mxr.mozilla.org/mozilla-central/source/security/nss/lib/ckfw/builtins/certdata.txt?raw=1
  ftp://ftp.mozilla.org/pub/security/nss/releases/
https://github.com/agl/extract-nss-root-certs.git

I'll try to remember to add this to the 'cert' ticket when I find
it again.


- CRYPTO: remove sslfingerprint? too easily abused (see NEWS)

I trust this is by now just an