#4916 Email replies disappear.
Closed: Fixed 3 years ago by pingou. Opened 3 years ago by rombobeorn.

Pagure sends emails that contain the text "To reply, visit the link below or just reply to this email". I sent an email reply. Two hours later it hasn't shown up in the web interface. I haven't received any kind of error message either. The words "or just reply to this email" should be removed because they are untrue.


It is supposed to work, but things have been wonky with the DC move...

Metadata Update from @ngompa:
- Issue tagged with: bug, email

3 years ago

It is supposed to work, but things have been wonky with the DC move...

Replying by email, let's see :)

Pagure sends emails that contain the text "To reply, visit the link below or just reply to this email". I sent an email reply. Two hours later it hasn't shown up in the web interface. I haven't received any kind of error message either. The words "or just reply to this email" should be removed because they are untrue.

Is the email you're sending From configured in pagure.io? Otherwise pagure will
discard any email it doesn't know about (I'll need to check the code again, but
it may even ask that the email address used be the configured default email
address).

Pierre-YvesChibon wrote:

Is the email you're sending From configured in pagure.io?

I was sending from the same address that Pagure uses to send to me,
except for casing. This time I've changed my address to all lowercase,
so it should match exactly.

OK, that apparently worked.

Although the local part of an email address is specified as case-sensitive, meaning that programs are not supposed to convert it between upper and lower case, I think you should use case-insensitive comparison for this purpose.

Otherwise pagure will discard any email it doesn't know about.

Rejected emails should be bounced, not discarded. Bouncing should be done in the SMTP session instead of accepting the message for delivery. That prevents turning spam into backscatter. The error message should state that the sender address wasn't recognized, so that the sender has a chance to fix the problem.

Rejected emails should be bounced, not discarded. Bouncing should be done in the SMTP session instead of accepting the message for delivery. That prevents turning spam into backscatter. The error message should state that the sender address wasn't recognized, so that the sender has a chance to fix the problem.

I don't understand what you mean with "Prevents turning spam into backscatter"
and the definition of backscatter I'm finding on wikipedia doesn't help me
either :(

Pierre-YvesChibon wrote:

I don't understand what you mean with "Prevents turning spam into backsca=
tter"
and the definition of backscatter I'm finding on wikipedia doesn't help me
either :(

If a mail server first accepts a message for delivery, and later
decides to reject it, then the only way to notify the sender is to
generate a delivery failure report and send it to the purported sender
address. If the rejected message was spam, then the sender address is
probably fake, and the delivery failure report ends up in some innocent
person's inbox. That is called backscatter.

To prevent backscatter, the decision to reject the message should be
made while the SMTP client is still connected. The server should send
an error code to the client instead of accepting the message. If the
client is a spambot, then the spamming attempt fails and nobody is
bothered. If the client is somebody's outgoing mail server, then that
server is supposed to send a delivery failure report to the sender.

This can be done with a milter, which integrates with an MTA (Postfix
or Sendmail), inspects selected data while the SMTP session is
underway, and instructs the MTA to accept or reject the message. The
milter also tells the MTA what status code and error message to send to
the client. I recommend 550 5.7.1 "The sender address isn't
recognized.".

Metadata Update from @pingou:
- Issue assigned to pingou

3 years ago

Login to comment on this ticket.

Metadata
Related Pull Requests
  • #4934 Merged 3 years ago